2,000 Greater & Lesser Mysteries/2,000 Greater and Lesser Mysteries.iso/computer/virus/mys00490.txt

Text File | 1994-06-10 | 576.3 KB | 12,192 lines

=========================================================================
Date:         Thu, 1 Sep 88 08:05:02 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Frank San Miguel <ACS1S@UHUPVM1>
Subject:      Re: Dup Mail
In-Reply-To:  Your message of Wed, 31 Aug 88 18:49:20 EDT

I received the mail about FluShot complaints twice.  Once I'd deleted it, then
it was there the next day...

Frank
=========================================================================
Date:         Thu, 1 Sep 88 09:19:34 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject:      Monthly info from Ken



[ Last modified 29-July-88 - Ken van Wyk ]

Welcome!  This is the monthly introduction posting for VIRUS-L,
primarily for the benefit of any newcomers.  Apologies to all
subscribers who've already read this in the past (you'll only have to
see it once a month and you can, if you're quick, press the purge
key...:-).


What is VIRUS-L?

It is an electronic mail discussion forum for sharing information
about computer viruses.  Discussions should include (but not
necessarily be limited to): current events (virus sightings), virus
prevention (practical and theoretical), and virus questions/answers.
The list is non-moderated and non-digested.  That means that any
message coming in goes out immediately.  Weekly logs of submissions
are kept for those people who prefer digest format lists (see below
for details on how to get them).


What isn't VIRUS-L?

A place to spread hype about computer viruses; we already have the
Press for that.  :-)  A place to sell things, to panhandle, or to
flame other subscribers.  If anyone *REALLY* feels the need to flame
someone else for something that they may have said, then the flame
should be sent directly to that person and/or to the list moderator
(that'd be me, <[e-mail]>).


How do I get on the mailing list?

Well, if you're reading this, chances are *real good* that you're
already on the list.  However, perhaps this document was given to you
by a friend or colleague...  So, to get onto the VIRUS-L mailing list,
send a mail message to <[e-mail]>.  In the body of the
message, say nothing more than SUB VIRUS-L your name.  LISTSERV is a
program which automates mailing lists such as VIRUS-L.  As long as
you're either on BITNET, or any network accessible to BITNET via
gateway, this should work.  Within a short time, you will be placed on
the mailing list, and you will get confirmation via e-mail.


How do I get OFF of the list?

If, in the unlikely event, you should happen to want to be removed from
the VIRUS-L discussion list, just send mail to
<[e-mail]> saying SIGNOFF VIRUS-L.  People, such as
students, whose accounts are going to be closed (like over the
summer...) - PLEASE signoff of the list before you leave.  Also, be
sure to send your signoff request to the LISTSERV and not to the list
itself.  Note that the appropriate node name is LEHIIBM1, not LEHIGH;
we have a node called LEHIGH, but they are *NOT* one and the same.


How do I send a message to the list?

Just send electronic mail to <[e-mail]> and it will
automatically be redistributed to everyone on the mailing list.  By
default, you will NOT receive a copy of your own letters.  If you wish
to, send mail to <[e-mail]> saying SET VIRUS-L REPRO


I can't submit anything to the list - what's wrong?

There have been a few cases where people found that they were unable
to send anything in to VIRUS-L even though they were registered
subscribers (only subscribers can participate).  Let me try to explain.
The LISTSERV program differentiates lowercase from UPPERCASE.  So,
if you've subscribed to the list as (for example) [e-mail]
and your mail is actually coming through as [e-mail], then
the LISTSERV will think that you're not subscribed to the list.
BITNET usernames and node names are automatically uppercased by
the LISTSERV, but other network addresses are not.  If your site
(or you) should happen to make a change to, say, the system mailer
such that it changes the case of your mail, there will be problems.
If you're having problems submitting (you'll know this because
the LISTSERV will say "Not authorized to send to VIRUS-L..."), try
unsubscribing and re-subscribing.  If that doesn't work, send me
mail ([e-mail]), and I'll try to fix things up.


What does VIRUS-L have to offer?

All submissions to VIRUS-L are stored in weekly log files which can be
downloaded by any user on (or off) the mailing list; readers who prefer
digest format lists should read only the weekly logs.  There is also a
small archive of some of the public anti-virus programs which are
currently available.  This archive, too, can be accessed by any user.
All of this is handled automatically by the LISTSERV here at Lehigh
University (<[e-mail]>).


How do I get files from the LISTSERV?

Well, you'll first want to know what files are available on the
LISTSERV.  To do this, send mail to <[e-mail]> saying
INDEX VIRUS-L.  Note that filenames/extensions are separated by a
space, and not by a period.  Once you've decided which file(s) you
want, send mail to <[e-mail]> saying GET filename
filetype.  For example, GET VIRUS-L LOG8804 would get the file called
VIRUS-L LOG8804 (which happens to be the monthly log of all messages
sent to VIRUS-L during April, 1988).  Note that, starting June 6, 1988,
the logs are weekly.  The new file format is VIRUS-L LOGyymmx where
yy is the year (88, 89, etc.), mm is the month, and x is the week
(A, B, etc.).  Readers who prefer digest format lists should read
the weekly logs and sign off of the list itself.  Subsequent submissions
to the list should be sent to me for forwarding.

Also available is a LISTSERV at SCFVM which contains more anti-virus
software.  This LISTSERV can be accessed in the same manner as outlined
above, with the exceptions that the address is <[e-mail]>
and that the commands to use are INDEX PUBLIC and GET filename filetype
PUBLIC.


What is uuencode/uudecode, and why do I need them?

Uuencode and uudecode are two programs which convert binary files into
text (ASCII) files and back again.  This is so binary files can be
easily transferred via electronic mail.  Many of the files on this
LISTSERV are binary files which are stored in uuencoded format (the
file types will be UUE).  Both uuencode and uudecode are available from
the LISTSERV.  Uudecode is available in BASIC and in Turbo Pascal here.
Uuencode is available in Turbo Pascal.  Also, there is a very good
binary-only uuencode/uudecode package on the LISTSERV which is stored
in uuencoded format.


Why have posting guidelines?

To keep the discussions on-track with what the list is intended to be;
a vehicle for virus discussions.  This will keep the network traffic
to a minimum and, hopefully, the quality of the content of the mail to
a maximum.  No one wants to read personal flames ad nausium, or
discussions about the pros and cons of digest-format mailing lists,
etc.



What are the guidelines?

     As already stated, there will be no flames on the list.  Anyone
     sending flames to the entire list must do so knowing that he/she
     will be removed from the list immediately.

     Same goes for any commercial plugs or panhandling.

     Submissions should be directly or indirectly related to the
     subject of computer viruses.

     Responses to queries should be sent to the author of the query,
     not to the entire list.  The author should then send a summary
     of his/her responses to the list at a later date.

     "Automatic answering machine" programs (the ones which reply
     to e-mail for you when you're gone) should be set to *NOT*
     reply to VIRUS-L.  Such responses sent to the entire list
     are very rude and will be treated as such.

     When sending in a submission, try to see whether or not someone
     else may have just said the same thing.  This is particularly
     important when responding to someone else's posting (which should
     be sent to that person *anyway*).  It's very easy to get multiple
     messages saying the exact same thing.  No one wants this to
     happen.

Thank-you for your time and for your adherance to these guidelines.
Comments and suggestions, as always, are invited.  Please address them
to me, <[e-mail]> or <[e-mail]>.



Ken van Wyk

Kenneth R. van Wyk                   Calvin: Where do we keep the chainsaws?
User Services Senior Consultant      Mom:    We don't have any!
Lehigh University Computing Center   Calvin: None?!  Mom: None at all!
Internet: <[e-mail]> Calvin: Then how am I supposed to learn
BITNET:   <LUKEN@LEHIIBM1>                   how to juggle?!
=========================================================================
Date:         Thu, 1 Sep 88 09:38:49 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ken van Wyk <[e-mail]>
Subject:      Re: Dup Mail
In-Reply-To:  Your message of Thu, 1 Sep 88 08:05:02 CDT

> I received the mail about FluShot complaints twice.  Once I'd
> deleted it, then it was there the next day...

Lets please keep any reports of duplicate mail off of the list.  If
anyone is having mail problems, please report them to me directly at
either [e-mail] or [e-mail].  Thanks!

Ken



Kenneth R. van Wyk                   Calvin: Where do we keep the chainsaws?
User Services Senior Consultant      Mom:    We don't have any!
Lehigh University Computing Center   Calvin: None?!  Mom: None at all!
Internet: <[e-mail]> Calvin: Then how am I supposed to learn
BITNET:   <LUKEN@LEHIIBM1>                   how to juggle?!
=========================================================================
Date:         Thu, 1 Sep 88 13:18:11 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         David Ascher <ST501649@BROWNVM>

Unsubscribe me.
Thank you.
=========================================================================
Date:         Thu, 1 Sep 88 13:06:47 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Frank San Miguel <ACS1S@UHUPVM1>
In-Reply-To:  Your message of Thu, 1 Sep 88 13:18:11 EDT

For what?
=========================================================================
Date:         Fri, 2 Sep 88 10:20:13 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Otto Stolz [phone] <RZOTTO@DKNKURZ1>
Subject:      MS-DOS: new strain of virus?

Hello experts,

last night one of our staff members detected evidence of a virus that has
infected every puplicly accessible AT or compatible at our department
(computing center of an university), and more than 50% of the ATs used by
staff persons only.  Meanwhile, I think I know how this virus spreads.
So far, it has not done any harm, but I do not know what it will do to
the befallen in future.

Please find details below.  Has anybody seen this particular strain of
virus before?  If so, what do we have to expect, if we do not succeed
in destroying all copies?  Please answer privatly to me to avoid unneces-
sary network traffic; I'll summarize to The List.

If this is a new strain, somebody (me?) will probably have to dis-
assemble it to find out, what threat it contains.  This will probably
last for a couple of weeks,  so do not expect quick results.  For this
task, I'll probably need a dis-assembler and a compare-program.  Who can
me tell, where to obtain such tools?

Thanks for your time, and best regards
                                        Otto

--------------

Symptoms:

1. Apparently, the virus makes itself core-resident and waits for some
   .COM or .EXE file to be started.

2. When a .COM or .EXE is started, the virus inserts itself into that
   very program, making it exactly 1704 Bytes longer, according to the
   DIR command.  If the program resides on a write-protected disk, the
   virus will cause a write-protect error, instead.

   No program is infected twice.

   I tried it with a pseudo program of 4 bytes (my 1st name), and found
   that after the infection these 4 bytes had apparently been over-
   written (visual inspection with TYPE only -- we'll use some suitable
   editor after des-infection).  A .COM and an .EXE file with the same
   file name and the same 4 bytes content yielded apparently identical
   infected files (visual inspection with TYPE only -- no comparison pro-
   gram run, so far), while another test case with a different file name
   and different contents (5 Bytes) showed a slight difference in the
   infected file.  Astonishingly, even these pseudo programs are termi-
   nated without any error message from DOS.

3. When you run the infected program on another computer, it will
   continue to infect every .COM or .EXE file started there.

Recovery:

We've begun to re-install software on the infected disks, proceeding
thus (thanks to VIRUS-L for many hints during the last couple of months):

1. On dedicated computers, backup the important data files.  Be sure not
   to backup any .COM or .EXE file.  Skip this step on public computers.
   (BTW, an incredibly stupid notion, a "contradictio in adjecto": these
   "public Personal Computers", we were forced to install on account of
   decisions by our government!  Now, we're experiencing the consequences
   of this oddity.)

2. Switch off the Computer.

3. Switch it on again, booting from a write-protected, original system
   disk.  Install the software again from write-protected originally
   vendor-supplied disks.

   On one computer, test for presence of the virus after installation of
   every software component, to make sure the virus doesn't come from a
   software package (vendors aren't immune, are they?? :-)

   On the publicly accessible computers, this step involves removing the
   SafeGuard Cards, installed therein.  We can't distribute the repaired
   software through the PC-Network, as this would require at least one
   .COM or .EXE file on the receiving side.  All we can do to save some
   labour, is installing the DOS and networking component on every com-
   puter, install the other components only on the server and re-distri-
   bute them from it.  (Again, you see the advantage of a host, where
   software is maintained only in 1 copy, over a pool of PCs!)

4. On dedicated computers, restore the backed-up files.

Apparently, we are facing pretty much labour to re-install everything
properly.

5. Try to develop some virus-recognizing program to avoid future
   infection from the same strain.  Still unsolved problem: how can we
   force every user to apply this program to her disks, before starting
   any .COM or .EXE???  Suggestions welcome!
=========================================================================
Date:         Fri, 2 Sep 88 13:57:20 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "M. Smith" <[e-mail]>
Subject:      A Modest Proposal


    With the mess that the nets are in right now, an idea that Info-Micro
went to on the Arpa side is due. Info-Micro distributes unmoderated Digests at
a once per day rate. The Digests may be sent twice on occasion, but as they
are numbered and dated, it is easy to eliminate substitutes and trail down
evil mailers in the net (not as much of a problem on ARPA/MILNET since the
topology is point to point. *FAILED* mail is the big problem, as the mailer
retries for three days and sends a copy of the failed mail to EVERY MEMBER OF
THE LIST _E_A_C_H_ _D_A_Y_ !!!) Unattended operation might make many people
happier, but semi-automatic operation is probably safer, although I would
rather get digests regularly, than one behemoth when the digester has been
away for two weeks. I will post any comments/flames I get, but you can send
mail directly to Ken (see his monthly blurb for his address) if you like this
idea. Send all disagreements to /dev/null ;-)

                    Thank you for your attention,
                    Mark L. Smith
                    [e-mail]

=========================================================================
Date:         Fri, 2 Sep 88 14:38:53 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ken van Wyk <[e-mail]>
Subject:      Re: A Modest Proposal
In-Reply-To:  Your message of Fri, 2 Sep 88 13:57:20 EDT

>     With the mess that the nets are in right now, an idea that Info-Micro
> ...
> idea. Send all disagreements to /dev/null ;-)

That's a suggestion that I'd considered a while ago, and I put it up
to a vote.  The bottom line was that most people preferred running
VIRUS-L undigested and unmoderated.  You can, of course, unsubscribe
and read just the weekly logs if you wish.  That's a pseudo-digest
list.  That's what the majority wanted.

Let's *please* not get into a debate about the pros and cons of
digest/non-digest.  I went with the majority vote.  Enough said about
digesting, ok?

Thanks,

Ken



Kenneth R. van Wyk                   Calvin's mom running a bath for Calvin...
User Services Senior Consultant      Calvin: It's too cold!
Lehigh University Computing Center   Calvin: Now it's too hot!
Internet: <[e-mail]> Calvin: Now it's too cold!
BITNET:   <LUKEN@LEHIIBM1>           Calvin: Now it's too deep!
=========================================================================
Date:         Fri, 2 Sep 88 14:50:00 CST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         conni annable <ANNABLE@UTHSCSA>
Subject:      SCORES spread question


Yesterday, we discovered that the MAC network in our Library was infected
with the SCORES virus. This was identified by INTERFERON V3.0. This morning
FERRET V1.1 was used to clean up the hard disks and the Library folks will
now go through their application diskettes and clean them up as well. A
major problem is that the network is publicly available (bring your own
diskettes). FERRET reported the infection dates - the earliest one
was May 23, 1988.

We seem to see some evidence that the virus has been spread through data
files. Does anyone know if this is possible? The other possibility is
that these (not extremely computer literate) users are not remembering
everything quite correctly, but we have at least one who clains to have
taken a disk containing "just the data I wanted to print" to this network
to use the laser printer, then contaminating a stand-alone MAC in another
location later with that disk. Thoughts?


Thanks,
Conni Annable
Network Manager and Virus Information Coordinator (whatever that means)
University of Texas Health Science Center at San Antonio

All opinions stated are entirely my own.
=========================================================================
Date:         Fri, 2 Sep 88 16:35:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Chris Bracy <[e-mail]>
Subject:      Yale Virus Info

I have noe dissabled the Yale virus entirely.  Here are some specifics...

There is a format table set up to format the 40th track for 8 sectors
/track.  The final bios is call is missing however so the format is
never done.

The virus copies itself  to high memory and reduces the MS-DOS memory
count by 1K.

It then reads the original boot sector which was kept on track 40,
sector 8, which is then executed.

This virus takes over two vectors: int 9 and Int 19.  Int 19 is the
reboot vector.  Int 9 is the keyboard vector.

The Virus only spreads on reboot.  If an infected disk was booted and
you do a warm boot (Ctrl-Alt-Del) it will infect the new disk.  The
keyboard handler has the logic to watch for this reboot.

The keyboard handler also has a hook for Ctrl-Alt-i.  If pressed the
virus copies it generation count to 40:72.  If I remember correctly,
(I cant figure out where I saw this originally) this location is
checked on reboot for 1234H.  If found it does a quick boot.  It is
possible that the writer wanted to make this a key for dont infect,
but on all machines I have access to, this isnt the case.

The virus resets the screen by putting a byte in memory.  This method
doesnt work correctly on new machines.  Instead of clearing the
screen, it converts it to 40 column mode.  (This is how it was
noticed)

This virus keeps a generation count.  It doesnt appear to use this
count for anything (except as mentioned above).  The version I got had
a generation number 14h.

The virus will jump to ROM basic if ti cannot load the original boot
sector.

I beleive this is either and old virus or written by someone with an
old machine.  The format is 8 tracks instead of the current 9.  The
jump for ROM basic is in.  The screen clear is done with a poke (this
does clear the screen on an original PC but not on newer machines.)
etc...

The virus infects almost any diskette, but it must be in drive A:
(eliminating hard drives).  It will only boot PC(XT) compatibles.  I
could not get it to boot an AT (I tried Zenith 248 and 286).  It will
also infect almost any version of DOS.  I have tried DOS 1.0 thru 3.3.

The virus has no harmful effects except for writing onto track 40.
Even on high density drives where this is in the middle of the disk.
If track 40 is written to after it is infected, it will cause the disk
to become unbootable.

If anyone has seen this virus, or has any questions, please drop me a
line.

Chris.



*==============================*======================================*
|       Chris A. Bracy         |         Student Consultant           |
|       [phone]         |  Lehigh University Computing Center  |
|  [e-mail]  |    Fairchild Martindale Bldg.  8B    |
|   [e-mail]    |           Lehigh University          |
|       [e-mail]     |          Bethlehem, PA 18015         |
*==============================*======================================*
=========================================================================
Date:         Fri, 2 Sep 88 16:32:12 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe McMahon <XRJDM@SCFVM>
Subject:      Re: SCORES spread question
In-Reply-To:  Message of Fri, 2 Sep 88 14:50:00 CST from <ANNABLE@UTHSCSA>

>FERRET V1.1 was used to clean up the hard disks....
Uh, I'd REALLY want to check over those files again if I were you;
Ferret 1.1 doesn't always clean up Scores completely...! Try KillScores
instead (available from our LISTSERV).

>We seem to see some evidence that the virus has been spread through data
>files. Does anyone know if this is possible?
No. Scores ONLY affects files which contain executable (CODE) resources;
details notwithstanding, unless you have VERY peculiar data files (with
CODE in them? Wow), you can't catch Scores from a data file.

Just as a thought -- Lightspeed C project files have code added to them;
this couldn't be the case here, could it? Also, get Vaccine on ALL of
your public machines, and teach the users that the Vaccine dialog means
biiiiiiiiig trouble. "Wanted" posters, e.g., "Has you seen this dialog?",
are a good way to do this. Vaccine is also available from LISTSERV@SCFVM;
please e-mail me directly if you'd like some help.

--- Joe M.
=========================================================================
Date:         Fri, 2 Sep 88 16:42:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
In-Reply-To:  Message of 30 Aug 88 09:10 EDT from "Frank San Miguel"


Frank San Miguel asks:

>That brings me to another point, if a war should take place
>(sensibilities forbiding),  how prominently would viruses be used as a
>means of attacking an enemy?  This sounds like the plot of a cheesy
>film.

I certainly prefer them to hydrogen bombs.

During the second world war, the US authorities used a different
currency in Hawaii than they did on the continent.  This was a defense
against counterfeit currency attacks.  Note that counterfeiting is
difficult except with the resources of a sovereign power.  There are
both a cheesy film and a cheesy tv series based upon the premise that
Nazi Germany had attempted to de-stabilize Great Britain by debasing its
currency with counterfeit.  (Both of these include a line about the
conscription of felons to help carry out the attack.)  To the best of my
knowledge there was never such an attack, even against the notoriously
easy to counterfeit US currency.

While such attacks make great fantasy, they do not make very good
warfare.  Both the US and Great Britain were very busy debasing their
own currency.  They did not need any help from the Axis powers.  While
colorful, these attacks are not nearly so damaging as bombs or
artillery, even though they may be cheaper.

the use of criminals also suggests that, even in wartime, there are
limits beyond which noble people do not go.  Counterfeiting and forgery
are the tactics of criminals.  Even spying has a taint to it.  Saboteurs
are dealt with much more severely than soldiers.

Viruses are the tools of the immature, the sneaks, and the cowards; not
those of the hero.

William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
=========================================================================
Date:         Fri, 2 Sep 88 09:57:00 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         KEENAN@UNCAMULT
Subject:      Re: Pc-Lock
In-Reply-To:  Message of 31 Aug 88 13:52 MDT from "James Ford"

I saw one case (a large government installation here in Calgary) in
which the user changed his CONFIG.SYS file (which the Pc-lock
documentation warns you not to do..who reads documentation?  :-) and was
then unable to access anything.  The remedy involved pulling the power
to the card I believe.

Tom Keenan Associate Professor Dept.  of Computer Science The University
of Calgary
=========================================================================
Date:         Fri, 2 Sep 88 18:51:38 +0300
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Y. Radai" <RADAI1@HBUNOS>
Subject:      CRC vs. encryption schemes

  Jerry Leichter writes:

>         Suppose I know how your polynomial generator works, and have a copy
>of ONE file with your checksum for it.  I proceed to compute the checksum of
>the file with all 70 million possible polynomials, comparing the results to
>the known checksum.  Even if it takes a second to compute, I can expect a
>match in a little over a year.

I have three replies to this:
  (1) Just where do you expect to get the checksum, relative to the generating
polynomial which I use for detection of viral infection, of even ONE file of
mine?  I'm certainly not going to publish one.  Are you going to get onto my
computer and peek at the files on my hard disk, hoping to find my checksum base
and hoping that the data isn't stored in encrypted form?  (If you should by some
chance succeed, you'll find my polynomial there too, without your even having to
compute it!)  Well, if my files were sufficiently important (or if I were suf-
ficiently paranoid) to think that someone would be willing to devote a year of
computer time for them, I would certainly keep my checksum base (and checksum
program) offline, on a diskette which I would keep locked up and which I would
insert into my computer only during the time I check my CRCs.
  (2) Assuming you have somehow managed to get ahold of one of my checksums,
by the time you come up with my polynomial after a full year (!!), I will have
changed my generator several times, and you will have spent an awful lot of
computer time for nothing!   Okay, for sake of argument let's suppose you pull
our your checkbook and purchase a real fast computer with parallel processors,
like the Cray 3 (*) if you can hold out another year until it's available.  Then
you could do it much faster, before I get a chance to change my generator.  But
again, if my files are sufficiently important, I will checksum each of them not
once, but twice or more, each time using a different generator.  So you got
*one* of my polynomials; so what?
  (3) Let's suppose for sake of argument that (a) I'm important enough for you
to devote all this computation time or power, (b) I use only one generator,
(c) I hand you one of my checksums, and (d) I haven't had time to change my
generator by the time you've computed it.  When all is said and done, you've got
a weapon only against *MY* files.  Now if you're interested in attacking other
people who use a personal/random CRC, you're going to have to go through all
that again for each and every one of them.  If, on the other hand, you're inte-
rested in attacking only me, you hardly need a virus; a simple immediate-acting
Trojan will do.  And in that case, *no* checksum program will help, no matter
how sophisticated or secure!  So tell me: Why bother calculating my polynomial
at all??


>Today, it is extremely naive.  The world is full of failed cryptosystems
>which people relied on because "no one could demonstrate a method" of breaking
>them.  Given advances in the field, the burden of proof should be - and, among
>people who work on these issues, IS - entirely on the PROPOSER of a system to
>show that his system is secure, in some sense.

In what *practical* sense have DES and RSA been shown to be appreciably more
secure than a Rabin-type CRC?  What I know is that RSA can be broken if someone
should find a reasonably quick way of factoring very large numbers.  I don't
seem to recall that the proposers of RSA have shown that to be impossible.
  As for DES (here I am relying mainly on an article by Tom Athanasiou in the
Risks Digest): (1) It was created essentially by modifying IBM's LUCIFER.  How-
ever the modifications seem to have been all in the direction of *weakening* it.
And the reason was evidently so that the code-breaking department of the NSA
would be able to *break* it when used by others.  Thus the key size was reduced
from 128 to 56 bits.  (2) Changes were also made in the S-boxes.  It has been
rumored that the NSA inserted a "trapdoor" into them in order to make the system
vulnerable; in any case, mathematicians have demonstrated the possibility of
weakening the cipher by introducing hidden regularities into the S-boxes.
(3) In 1985, the NSA abandoned DES.  At that time its deputy director for commu-
nications security was quoted as saying that he "wouldn't bet a plugged nickel
on the Soviet Union not breaking [DES]".  So whatever theoretical criteria DES
may satisfy, its proposers have not only not shown the system to be secure in
practice, but they have even abandoned it on grounds of its being *in*secure.

  Of course, you might reply, there's no *absolute* guarantee of security with
*any* system.  Well, it seems to me that the difference between our views lies
in where to draw the line between the insufficiently secure and the (apparently)
sufficiently secure.  The brute force scheme which you describe may be worth-
while if you're trying to *break a cipher* of some important intelligence or
military agency.  (The fact that you refer me to Kahn's book strongly suggests
that that's the application you have in mind.)  But we here on the list are
concerned only with virusbusting.  Of course, cryptographic techniques are
welcome for that purpose.  But one has to keep a proper sense of proportion.
It's straining the imagination to suppose that the ordinary type of virus
creator would spend over a year of computer time to break a CRC checker used for
viral detection purposes by ordinary individuals or institutions, and *that* is
the community *I* am concerned with.  These people need a *fast* algorithm with
*reasonably* high degree of security, and (present-day) cryptosystems simply
can't meet the first of these two requirements.
  Your standards concerning security are presumably much higher than mine, while
the increased execution time demanded by cryptosystems doesn't seem to play the
slightest part in your considerations.  Hence you apparently draw the line I
mentioned above  somewhere between a 31-bit CRC and DES.  But for the purposes I
have described, it suffices to draw it between a fixed-generator CRC and a
personal/random one.

  Besides, by emphasizing brute-force methods of breaking schemes, you miss the
*real* danger; "real" because it's *MUCH* more likely to be employed by a virus
creator than a brute-force method.  As I said in my posting of Aug. 29, that
comes from certain *loopholes* which must be blocked by the program utilizing
the checksum algorithm.  Without such blocking, *no* checksum algorithm, no
matter how sophisticated, can provide dependable detection of viral detection.
My program has them.  Does yours....??

                                           Y. Radai
                                           Hebrew Univ. of Jerusalem


(*) For those unfamiliar with the Cray 3, they say it's so fast, it can complete
    an infinite loop in six minutes.
=========================================================================
Date:         Sun, 4 Sep 88 17:05:04 +0200
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Y. Radai" <RADAI1@HBUNOS>
Subject:      Re: MS-DOS: new strain of virus?

Otto,

  The virus you describe seems to be similar, in general terms, to the Israeli
virus (which was described in VIRUS-L several months ago), although the details
seem to be slightly different.

  I'm sending you a separate file containing a program IMMUNE (in uuencoded
form).  Execute that, and if your virus is similar enough to ours (captures int
21h to control program execution), IMMUNE should prevent future infection and
warn you each time an attempt is made.

  If you want further help, send me a copy of a small COM file and a small EXE
file which are infected by your virus (actual programs, please; no psuedos).  If
all goes well, we'll be able to modify our program for removing the virused
portion of infected files so that it works on your virus too, avoiding the need
for you to perform the re-installation procedure you described.

                                           Y. Radai
                                           Hebrew Univ. of Jerusalem
=========================================================================
Date:         Mon, 5 Sep 88 11:50:00 URZ
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         BG0@DHDURZ2
Subject:      DES security (was: DES vs. CRC)

Hi folks,

some people mentioned that the DES is insecure because it only allows
a 56 bit key. That's not correct: DES allows a 768 (!!!!) bit key!
How to use this key length? Skip the key schedule routine and fill
in your own 16 48-bit-keys K1,...,K16. Going this way, you have
16 times 48-bit = 768 bits.
I really believe that the NSA, sorry the NBS dropped DES not because
of its insecurity but because its *too* secure (you know what I mean :-)
The NSA declared to develop its own encryption standard without help
from firm outside (like IBM in the case of DES). So nobody will be
able to have a look on the algorithms. So the NSA can do what she
want.... for example to make sure that they can read everything they
want to read....

All the best,
Bernd.
........................................................................

+----------------------------------------------------------------------+
| Bernd Fix          |   EARN:   BG0@DHDURZ2  or  BG0@DHDURZ1          |
| Bergheimer Str.105 |   UUCP: ...!pyramid!altger!doitcr!rnihd!bernd   |
| 6900 Heidelberg    |         ...!unido!tmpmbx!/                      |
| West Germany       | (from BITNET):     bernd%rnihd%tmpmbx@DB0TUI6   |
|                    |  VNET (VoiceNET):  [phone]              |
+----------------------------------------------------------------------+
| " ... 10010010011010100100110100100100101001110110100101101010 ...   |
|   This doesn't look like a cry for help, more like a warning!      " |
|                                                   From ALIEN, part I |
+----------------------------------------------------------------------+
=========================================================================
Date:         Tue, 6 Sep 88 02:35:59 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Amanda B Rosen <[e-mail]>
Subject:      Re: SCORES spread question
In-Reply-To:  Your message of Fri, 2 Sep 88 14:50:00 CST

Re: The library infected with scores-

If this is the SCORES virus that we've seen before, there is NO CHANCE that
a data file can carry this virus.

There is the minute possibility that somebody has modified the virus. I hope
not, it was pretty nasty already...

/a
=========================================================================
Date:         Mon, 29 Aug 88 14:12:12 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         GUYDOSRM@SNYPLABA

With regard to sending a virus for study...

I presume that the terms sterilize, disable, kill, destroy, etc.,
may not be synonyms.  What's the difference, if any?  Are there
any more-or-less agreed on definitions?

Ray Guydosh - State Univ of NY @ Plattsburgh
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
=========================================================================
Date:         Tue, 6 Sep 88 12:45:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
In-Reply-To:  Message of 29 Aug 88 15:12 EDT from "GUYDOSRM%SNYPLABA.BITNET at
              CUNYVM.CUNY.EDU"


I use "sterilize" and "disable"  to convey the notion of preventing
reproductive behavior while preserving other information and perhaps
even other behavior.  I use "kill" and  "destroy" both in the sense of
destroy; i.e., erase, delete, and overwrite.

William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
=========================================================================
Date:         Tue, 6 Sep 88 10:19:00 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      Virus wars

> From: [e-mail]
>
> Viruses are the tools of the immature, the sneaks, and the cowards; not
> those of the hero.

That could be said of the atom bomb, too, but when the time came it was used,
it worked, and it probably saved countless lives.  I don't intend to spend my
time writing viri, but if my country is threatened and a virus is what it
takes to alleviate the threat, you're going to see me crank out a virus so
fast it makes your head spin!

Malcolm Petcher
Texas Instruments, Inc.
=========================================================================
Date:         Tue, 6 Sep 88 16:48:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments:     Warning -- RSCS tag indicates an origin of SMTPUSER@OBERLIN
From:         "$CAROL@OBERLIN (BITNET)" <$CAROL@OBERLIN>
Subject:      hypercard virus question

My colleague (bitnet address PRUSSELL@OBERLIN) asks:

        Does anyone know if Hypercard stacks are capable of carrying
        Macintsosh viruses?  Are they considered applications or data?

Thanks much.

        |  Carol Conti-Entin   [phone]
        |  $carol@oberlin   -or-   pconti@oberlin  (BITNET)
        |  Academic Computing Consultant
        |  Houck Computing Center
        |  Oberlin College
        |  Oberlin, OH  44074
=========================================================================
Date:         Wed, 7 Sep 88 09:14:36 SET
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Christian J. Reichetzeder" <REICHETZ@AWIIMC11>
Subject:      Re: Virus wars
In-Reply-To:  Message of Tue,
              6 Sep 88 10:19:00 CDT from <[e-mail]>

>> From: [e-mail]
>>
>> Viruses are the tools of the immature, the sneaks, and the cowards; not
>> those of the hero.
>
>That could be said of the atom bomb, too, but when the time came it was used,
>it worked, and it probably saved countless lives.  I don't intend to spend my
>time writing viri, but if my country is threatened and a virus is what it
>takes to alleviate the threat, you're going to see me crank out a virus so
>fast it makes your head spin!
>
>Malcolm Petcher
>Texas Instruments, Inc.
It did save  lives, yeah? Even it did  it did so only because no  one else had
it. If the Japanese would've had it then ...
And if  "your country" - as  you want to see  it - is threatened  (by "someone
elses country",  I assume) and you  decide to release  a virus I feel  you are
threatening  my country  also  (or  can you  guarantee  that  "my country"  is
spared?) and  I will not hesitate  to take appropriate counter-action  and ...
you see where this  leads to. And maybe I should start right  now - my country
is threatened  by atom bombs since  they were invented. So  all countries with
ICBMs and nuclear warheads watch out!
*flame off*
Christian
=========================================================================
Date:         Wed, 7 Sep 88 08:24:07 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe Simpson <JS05STAF@MIAMIU>
Subject:      Hypercard as a virus vector

The famous "birthday" virus is reported to have been introduced into a
hypercard stack loaded onto compuserve.

As a general answer, hypercard is a fertile medium for virus infestations.
HyperTalk itself contains many commands supportive of this end and there are
publicly available extensions as XCFN's and XCMD's that will finish the job.
=========================================================================
Date:         Wed, 7 Sep 88 10:16:44 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         OJA@NCCIBM1

In an earlier posting warning about human frailities and computer
security, it seems that the intense dramitic scenario touched off a
discussion about viruses in warfare. Fascinating exchange of comments
but I should put an important comment here...

The scenarios were extreme case. The depiction of viruses used for
"political" reasons was intended to be depicted as being sought by
groups more used to working outside of the regular conventions of
law, and other social constraints. Most likely candidates if this were
ever to happen would be terrorist groups which are already oriented to
working outside of normal bounds. Besides this orientation, another
factor enters- the difference in perspective from that of governmennts.
Many governments would be far more cautious realizing that they have
much to lose and that they have a "return address" should some crazy
"viruses war" scheme be attempted and discovered. They also know,
hopefully, the danger of things getting out of control when the modes
of C3I - communications, command, control, and intelligence - get
severely disrupted. Such disruption rather than leading to miltary or
political success could, in this age, lead to a lethal panic. So, I
doubt that as a form of "warfare" viruses would be serious considered
by most countries.

For "outsider" groups, the changes are higher. But still very low,
except for small scale harrassment. I have gotten reports on some
groups using variety of computer means to harrass opposing groups.
But these have very localized and very temporary. (And quite
illegal.) The overall picture of terrorism and computers is that if
terrorist want to disrupt a computer center, they used more crude,
physical means- arson, explosives, etc. To date, there has been no
substantiated report of computer viruses used for political /
terroristic motives. (The Hebrew University case was reported in some
articles in US papers as a politically motivated viruses. That was an
erroneous report. The allegation may have happened from the combination
of "excitment" on the part of the writers and from an easy misunder-
standing or misrendition of the Hebrew word Mechabel (can mean eith
either sabateur or a terrorist.))

So this picture of "virus wars" is mentioned as possibilty among many
others, but a low probability one. The biggest threat of viruses
still remains the "hackers" and the innocent vectors. As for the
specific targetted use of viruses, the greater likelihood would
be "insiders" seeking revenge or some other self-oriented goal.
=========================================================================
Date:         Wed, 7 Sep 88 10:56:18 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "James N. Bradley" <ACSH@UHUPVM1>
Subject:      Re: Virus wars
In-Reply-To:  Your message of Wed, 7 Sep 88 09:14:36 SET

Gentlemen, Gentlemen...

War is not an instance of rational minds at work.  Rather, it is the failure of
 rational minds.  Viruses also might be considered a failure of an otherwise
rational mind.  Regardless, in the event of a war, I think we can assume that
both sides will be doing whatever they can to disrupt whatever they can.

I think the question should be something on the order of "Will the exchange of
computer viruses be so detrimental that no one will instigate it?"  This is
approximately the situation with nuclear weapons.  As with nuclear weapons,
both sides may seek the capacity to win with a first strike, but neither is
likely to achieve that capacity given the "roughly" equal resources.

This presumes of course, that this warrants further discussion on this
list.

JB
=========================================================================
Date:         Wed, 7 Sep 88 10:55:00 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Bernie <BSWIESER@UNCAMULT>
Subject:      Legality

If you get infected by an original piece of software straight from the
manufacturer, can you sue the software company in question for damages?
=========================================================================
Date:         Wed, 7 Sep 88 10:54:00 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Bernie <BSWIESER@UNCAMULT>
Subject:      Virus vs. Virus

Since many of the virus out there have been identified, why doesn't
someone write a "good" virus which can hunt them down and remove them?
Fight fire with fire.  I was recently hit by a virus on an SE which
blasted the hard drive.  Lots of work down the tubes by a worm I've
never seen before.
=========================================================================
Date:         Wed, 7 Sep 88 19:01:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Daniel M. Greenberg" <DMG4449@RITVAX>
Subject:      Virus Legislation

I'm not going to go on a long strung lecture about this, but I don't feel
that viruses should be illegal to write for several reasons.  First of all,
it would be virtually impossible to monitor this to the extent necessary
for it to be taken seriously and obeyed.  Take software piracy- illegal,
unmonitored, and rampant - nobody is afraid of being prosecuted for copying
a piece of software because it doesnt happen.  Second of, its a matter of
freedom.  Many anti-porn people think that all pornography should be taken
off the newsstands and not allowed to be sold.  That in itself would be
a crime- to take away one's freedom of choice.  Nobody is forcing a person
to buy such reading material if they don't want it.  What I write as a
programmer sould be my own business!  Many viruses are contracted by people
that download unknown software from bulletin boards.  If they didn't down-
load it, it wouldn't have propegated in their system.  Every time you download
something- you take a risk that it has a nasty virus.  If you go to a store
and buy a program, you can expect it to be "clean".  I believe that the
concept should be something like this:  It should be illegal to write or
distribute software that is intentionally made to destroy information of
any sort - unless that is the intention of the software, and quite clearly
stated so.  One purpose of a virus could be:  a small company doesnt want
any of its employees stealing its confidential database/software/etc- so
they install a time-bomb, and keep resetting it periodically, but if an
emmployee were to steal the disk, they wouldn't know how to reset it, and
it would self-destruct.  Also, any software written out of malace to
intentionally destroy information should be anywhere from a misdemeanor
to a felony depending on the scope of the damage/criminal record/etc.  I
believe that the most important area to focus on at first is the corporate/
university level.  This is where the most dammage can be caused.  Viruses
entering corporations/schools have been known to have devistating damage-
and thus should be dealt with very strictly.  Basically, what I'm saying
is that one should be able to write whatever one wants to- consider it freedom
of the press, supression is not the american way, however if one actually
uses a virus- then action should be taken.  Remember: you can talk about
shooting the president, there's nothing illegal about that, but if you actually
do so: then you are legally liable.  You have the freedom to make your own
decisions and then decide the consequences.

Box # 1026                        Daniel M. Greenberg
25 Andrews Memorial Drive         Rochester Institute of Technology
Rochester, NY  14623              Computer Engineering Technology '92

BITNET     : DMG4449@RITVAX
INTERNET   : [e-mail]
UUCP       : {psuvax1,mcvax}!ritvax.bitnet!dmg4449
Compuserve : 71641,1311               GEnie: D.GREENBERG2
PHONENET   : [716] 475-4295 <between 9am-10pm please!>

"The answer is 42."               "I hate quotations."
 (Deep Thought)                   (Ralph Waldo Emerson)
=========================================================================
Date:         Wed, 7 Sep 88 19:05:23 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         ENGNBSC@BUACCA
Subject:      Re: Virus vs. Virus
In-Reply-To:  Message of Wed, 7 Sep 88 10:54:00 MDT

Re: "Good" virus

Hmmm - sounds like some genetic research controversies lately...

Actually, I would rather blow away the infected files and go to
my most recent backup then risk putting a virus in - What if the
"good" virus gets perverted?  (could be almost as fun as the
micro copy protection battles...)

Besides, why do with a virus what can be done with a normal program?
For the Apple //s, there are a number of programs that look for symptoms
of known viruses and inform you of their presence - the same task I take
it that your "good" virus would perform.  The added risk of a virus
just doesn't justify to me the risks involved.
just doesn't justify to me the risks involved when all I need to do is
run a virus detector on any executable additions to my system, and every
once in a while to catch any requiring an incubation period.

=========================================================================
Date:         Wed, 7 Sep 88 20:22:31 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      Hypercard as a virus vector
In-Reply-To:  <QUCDN.X400GATE:LVw@Y@YZ*>

What is Hypercard? Is it a command language like REXX, or what?

                                       __________________________________
                                      |                                  |
David Slonosky/QueensU/CA,"",CA       |         Know thyself?            |
<SLONOSKY@QUCDN>                      |  If I knew myself, I'd run away. |
                                      |__________________________________|
=========================================================================
Date:         Wed, 7 Sep 88 20:28:01 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      Different Operating Systems

I was just wondering what the relatvie susceptibility of each available
operating system on the market was, in terms of security from viruses
and other nasties. We can tell that IBM and PC/MS-DOS are fairly
leaky just from reading this discussion. What about the operating
systems of Ataris, Amigas, Macintoshes? Do they all share the same
kind of open environment that DOS possesses? Is anyone more/less
susceptible to viruses? Are any of them harder/easier to write
viruses for? Are any of them harder/easier to protect? I suspect
the answer is that they are all equally vulnerable, but curiosity
demands that I ask.

From previous items, I know that mainframes and such
are the hardest to infect, so I won't ask about them here.


                                       __________________________________
                                      |                                  |
David Slonosky/QueensU/CA,"",CA       |         Know thyself?            |
<SLONOSKY@QUCDN>                      |  If I knew myself, I'd run away. |
                                      |__________________________________|
=========================================================================
Date:         Wed, 7 Sep 88 21:54:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         EAE114@URIMVS
Subject:      Suits for Viruses

+ If you get infected by an origional piece of software strait from the
+ Manufacturer, can you sue the software company .... ?
-
Yes.   You'd probably even win.   You MIGHT even get compensation
beyond the cost of the sofware and clean-up, but I doubt it.
-
You can sue anybody for anything.   Winning the suit is
sometimes based on precedent, sometimes on who spends the
most money, and frequently on random chance...
=========================================================================
Date:         Wed, 7 Sep 88 22:05:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         EAE114@URIMVS
Subject:      'Good' Viruses

... Why [not] write a "good" virus which can hunt them
[bad viruses] down and remove them?
-
1:  Its hard enough to predict what a program is
    going to do on YOUR system.  What it does on
    someone elses, and the systemic behavior as it
    propagates is REALLY hard to predict.
-
2:  It is even easier to modify an existing virus that
    used to be 'good' than it is to write a 'bad' virus.
    (not that either one is hard...)
-
3:  In order for your 'GOOD' virus to survive, you must leave
    holes in your security.   These holes are available to
    'bad' viruses as well as yours.
-
4:  There is no need for a virus killer to be self-propagating.
    People are perfectly willing to run the virus-killers by
    themselves.   Inserting the virus-killing code INTO other
    programs serves no purpose.
-
        >   (Eristic:  EAE114@URIMVS)=========================================================================
Date:         Wed, 7 Sep 88 22:34:00 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      Virus wars

> From: "James N. Bradley" <[e-mail]>

> Gentlemen, Gentlemen...

> War is not an instance of rational minds at work.  Rather, it is the failure
> of rational minds.  Viruses also might be considered a failure of an otherwise
> rational mind.  Regardless, in the event of a war, I think we can assume that
> both sides will be doing whatever they can to disrupt whatever they can.

Exactly.  It is a time of desparation, and desparate measures are taken, if
they offer the hope of an end to the war on terms acceptable to whoever takes
the measure.

> I think the question should be something on the order of "Will the exchange of
> computer viruses be so detrimental that no one will instigate it?"  This is
> approximately the situation with nuclear weapons.  As with nuclear weapons,
> both sides may seek the capacity to win with a first strike, but neither is
> likely to achieve that capacity given the "roughly" equal resources.

Though I initiated that analogy, I must point out a major difference:  Viri
are capable of being stealthy.  A modern nuclear attack would quickly be
followed by retaliation, and quite likely a no-win situation for both
parties.  The use of nuclear weapons in WWII was successful because it was
controlled and necessarily unilateral.  Such would not be the case today.  On
the other hand, given the resources, it is possible a stealthy virus could be
developed and injected into a target computer operated by some hypothetical
enemy, that might do it's dirty work undetected - degrading system
performance, perhaps causing the system to generate wrong results, or maybe
simulating hardware failures.  We haven't thus far seen a virus that behaves
that way, only because the only known reasons for anybody to write a virus so
far have been misguided mischief, and perhaps revenge.  When and if the
reasons for creating viri change, the behavior of them will change as well.

Malcolm Petcher,
Texas Instruments, Inc.
=========================================================================
Date:         Thu, 8 Sep 88 08:53:40 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject:      Virus case goes to trial (reprinted from RISKS forum)



     Here's an interesting article that appeared in a recent RISKS
     forum that I thought some of you may enjoy (except, of course,
     those who are already on the RISKS forum...):


Date: Wed, 07 Sep 88 13:05:09 EDT
From: Joe Morris ([e-mail]) <[e-mail]>
Subject: A Computer Virus Case Goes to Trial

From the _Washington_Post_, 7 September 88, page C-1 (without permission):

  JURY SELECTION IN 1ST `VIRUS' TRIAL BEGINS (AP)

Fort Worth, Sept. 6 -- Jury selection began today in the criminal trial
of a 40-year-old programmer accused of using a computer "virus" to sabotage
thousands of records at his former work place.
The trial is expected to last about two weeks.

Donald G. Burleson faces up to 10 years in jail and a $5,000 fine if convicted
in the trial, a first for the computer industry.  Burleson was indicted on
charges of burglary and harmful access [sic] to a computer in connection with
computer damage at a securities firm, said Nell Garrison, clerk of the state
criminal district court in Fort Worth.  Through his lawyer, Jack Beech,
Burleson denies the charges but has declined further comment.

The firm has been awarded $12,000 in a civil lawsuit against Burleson.
Pretrial motions were scheduled to be heard today, followed by jury selection,
Garrison said.

Burleson is accused of planting a piece of computer software known as a
virus in the computer system at USPA&IRA Co. two days after he was fired.
A virus is a computer program, often hidden in apparently normal computer
software, that instructs the computer to change or destroy information at
a given time or after a certain sequence of commands.  [Trojan horse???]

USPA officials claim Burleson went into the comapny's offices one night and
planted a virus in its computer records that would wipe out sales commissions
records every month.  The virus was discovered two days later, after it had
eliminated 168,000 records.

Kenneth R. van Wyk                   Calvin: Ever consider the end of the
User Services Senior Consultant        world as we know it?
Lehigh University Computing Center   Hobbes: You mean nuclear war?
Internet: <[e-mail]> Calvin: I think Mom was referring to if I
BITNET:   <LUKEN@LEHIIBM1>             let the air out of the car tires again.
=========================================================================
Date:         Thu, 8 Sep 88 00:30:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Jim Shaffer, Jr." <SHAFFERJ@BKNLVMS>
Subject:      request for info on an Atari 8-bit series virus

About a month ago I read in Atari Explorer magazine, in an article on viruses
in general, that there was a virus for the Atari 8-bit series of computers
(i.e., 800, 800XL, 65XE, 130XE).  However, the article didn't go into detail.
Has anyone heard of this virus and can tell me more?

Thanks in advance,
Jim Shaffer, Jr.

P.S.:  The article is a good overview of viruses in general, and I'll
post the information on where it appeared as soon as I can find the darn
magazine :-)
=========================================================================
Date:         Thu, 8 Sep 88 10:37:58 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "James N. Bradley" <ACSH@UHUPVM1>
Subject:      Re: Hypercard as a virus vector
In-Reply-To:  Your message of Wed, 7 Sep 88 20:22:31 EDT

Hypercard is a programming language disguised as a Macintosh application.
It uses hypertext and an index card analogy with a graphic interface to
allow virtually anyone to program, which has, as a consequence, produced
all kinds of cute but useless programs.

On the other hand, when people who know what they are doing write "stacks"
(Hypercard programs) they can be really spectacular.

I don't think you can compare Hypercard to REXX because of the difference in
the environments.  Hypercard has a strong graphic emphasis, it is designed
for anyone to use, and it will (probably) be the front end program of the
future for the Macintosh interface.

JB
=========================================================================
Date:         Thu, 8 Sep 88 11:47:00 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David D. Grisham" <DAVE@UNMB>
Subject:      Possible nvir

A user (Mac) has come to me with a disk with the following symptoms:

1) Would not save/print on MS word 3.01.
2) Used Ferret and code id 02, crashed.
3) Used VirusRx and declared "probably good"
4) Resedit found a non sequential code of 255,256, ...
Is this a Virus or a bad MS word?

******************************************************************************
*                                                                            *
*   Dave  Grisham                                                            *
*   Senior Staff Consultant                         Phone [phone]     *
*   Information Resource Center                                              *
*   Computer & Information Resources & Technology                            *
*   University of New Mexico                        USENET [e-mail] *
*   Albuquerque, New Mexico  87131                  BITNET DAVE@UNMB         *
*                                                                            *
******************************************************************************
=========================================================================
Date:         Thu, 8 Sep 88 07:01:14 PDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Robert Slade <USERCE57@UBCMTSG>
Subject:      Easiet OS to infect

     All inter system rivalry aside, the bigger they are, the more places
there are to hide.  My reading of the collected virus reports indicates that
the Mac is winning in the "I got more viri than you" stakes.  When OS/2
Extended is released (on 22 1.44 meg disks no less?), oi vey.  (Yes, yes, I
know. The kernel will be smaller than that.)
=========================================================================
Date:         Thu, 8 Sep 88 06:40:22 PDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Robert Slade <USERCE57@UBCMTSG>
Subject:      Viri in data files

     Carol raised the question about Hypercard, and "abr1" made a statement
that data files could *not* carry viri.  Let's be careful about what we
define as data.  (After all, programs really are just data that you execute.)
Both Hypercard, in the Mac world, and Lotus 123 files, to give an example in
the MS-DOS world, are capable of carrying commands that can do low level work
in your system.  Hypercard stacks at one point carried the Brandau "Macmag"
virus.  (I do not know of any incidents with Lotus workspaces ... yet.)

Robert Slade
=========================================================================
Date:         Thu, 8 Sep 88 15:06:41 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe Simpson <JS05STAF@MIAMIU>
Subject:      Re: Easiest OS to infect

In reply to the comment that bigger is easier to infect  I beg to differ.

Operating systems with layered architectures and rich file support are
easier to infect.  They may also be easier to defend with.  There is an
easy to use suite of public domain and sharware tools available.

I can only hope th
=========================================================================
Date:         Thu, 8 Sep 88 16:19:44 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ed Nilges <EGNILGES@PUCC>
Subject:      Re: Viri in data files
In-Reply-To:  Your message of Thu, 8 Sep 88 06:40:22 PDT

Hypercard stacks have two capabilities as virus vectors:

     1.  Those without XFCN and XCMD coding probably cannot screw up
         the Mac environment outside of Hypercard, but they can screw
         up a given instance of Hypercard by setting global properties
         in a subtle way.

     2.  Those with XFCN/XCMD can screw up the Mac, in addition to the
         Hypercard environment.

This may indicate an automated test to see which class a given stack
falls into.  The fact that the first class is relatively benign does
not entail that we should never worry about class 1 Hypercard viruses,
only that we should focus the bulk of our (always limited) virus-fighting
resources on class 2 viruses.

Note also that Hypertalk lets you treat stacks as objects...this raises
the specter of fearsomely complex, self-altering Hypercard stacks
circulating around bulletin boards and such.  The fact that Hypercard
stacks can be entertaining (music, X-rated cartoons, and so on) will
speed viruses along this particular vector.
=========================================================================
Date:         Thu, 8 Sep 88 15:07:00 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Bernie <BSWIESER@UNCAMULT>
Subject:      Re: 'Good' Viruses
In-Reply-To:  Message of 7 Sep 88 20:05 MDT from "EAE114 at URIMVS"

(This is a weak, but so are most args.)
Sure, any person who knows about viruses can run an anti-viral program but
don't forget MOST computer users are not computer or computing literate.
I really doubt that a "good" virus could easily be corrupted.  After all, how
many people do you know who trace other peoples ml code for fun?  The whole
purpose of this hypothetical "good" virus would be to remove only identifiable
"bad" viruses, and maybe after a certain time remove itself.  It would be
doing the techno peasant a favour as well as the knowledgable because you'd
never know it was there (just like a bad virus) doing the user a service.

Next: OJA, hackers are not to blame.  I resent that since not all hackers
are innately evil, and hacking is a proven learning experience.
Greenberg, you forget the Shareware protection (one of many).  "Send us your
money or else it won't work after a while..."  Anyone know how many pieces of
Shareware have trojan horses?

=========================================================================
Date:         Thu, 8 Sep 88 13:02:23 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         me! Jefferson Ogata <OGATA@UMDD>
Subject:      good viruses/bad viruses

We had a discussion about the merits of making virus-protection software
viral itself some months ago.  I'm hearing a lot of the same rebuttal
again, and it makes no more sense this time than last.

Correctness: how do you know your virus will behave the same way in some
other environment and not do serious damage?  How do you know ANY program
will behave as you expect?  Why bother writing programs?  They might turn
into Trojans.  Surely this is paranoia.  Viruses are programs.  You can
test them.

Superfluosity: a virus cannot do anything a regular program can't do.
Yes it can.  A virus can self-propagate.  A virus is immune to virus
attacks, unlike most virus-protection software.  Even encryption schemes
have the glaring flaw that they can be corrupted.

Insecurity: you must leave holes through which the virus can propagate.
Well, if those holes could be closed, there would be no need for the
good virus.  As long as those holes exist, the virus can do some good.
And nothing stops you from plugging all the holes you can; you'll prevent
good viruses from propagating, but hopefully you'll prevent the bad ones
from propagating as well.

Mutation: what if the virus gets corrupted and becomes damaging?
Programs don't mutate so any corruption would have to be some kind of
hardware problem.  In that case, the probability is much higher that some
particular program will become a Trojan.  It is virtually impossible for
some random alterations in code to end up functional, let alone damaging.
The virus code would be small and therefore less likely to be damaged.

Bad guys: someone might take the code and alter it to be bad.  True.

- Jeff Ogata
=========================================================================
Date:         Thu, 8 Sep 88 09:32:50 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Jim Marks <JMARKS@GTRI01>
Subject:      Re: Legality
In-Reply-To:  Message of Wed, 7 Sep 88 10:55:00 MDT from <BSWIESER@UNCAMULT>

This is a good question.  I'm not a lawyer, so I can't really answer it, but
will offer my opinion.

You can pretty much sue anyone you want, the question is whether you would
(or could) win.  Even lawyers often can't answer this; it depends on the state,
judge, jury (if any), etc.

Most of the software licence agreements have statements which say the vendor
is not liable for damages as the result of using the software.  Of course, the
"agreements" also usually say something to the effect that the vendor doesn't
even guarantee that the program will do what you need to do, either.  In fact,
if you saw disclaimers on cars (or other products) of the sort on software
packages, you would never buy them.

I question whether such agreements have legal validity, but then I'm not a
judge.  What would also be an interesting case would be such things as
structural design software which was used in the design of a building.  If the
building design was not adequate (because of a "bug" in the software) and the
building collapsed (say with loss of life), could the damaged parties prevail
against the software manufacturer (in addition to the structural engineer)?
Could the structural engineer prevail against the software manufacturer?
I think there will eventually be some interesting cases of this sort (maybe
not quite so dramatic) in the future, if not already.

Back to the virus...
What would be difficult in such a case (even if the license agreement didn't
protect the vendor) would be proving that the virus actually came from the
vendor's package.  These things, by their nature, are pretty elusive.

These are strictly my opinions; I don't even pretend to be an authority in
this area.  Anyone out there who is?

Jim Marks
=========================================================================
Date:         Thu, 8 Sep 88 18:13:49 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David A. Bader" <DAB3@LEHIGH>
Subject:      Re: Viruses

>I really doubt that a "good" virus could easily be corrupted.  After
>all, how many people do you know who trace other peoples ml code for
>fun?  The whole purpose of this hypothetical "good" virus would be to
>remove only identifiable "bad" viruses, and maybe after a certain time
>remove itself.  It would be doing the techno peasant a favour as well
>as the knowledgable because you'd never know it was there (just like a
>bad virus) doing the user a service.

Look at viruses such as the Brain virus and others that have been
modified through time.  Random programmers out there are easily able to
decompose the ML code and change good to bad, or from bad to worse.
Also, All the virus protection out there that watch for file size
changes, CRC checksums, etc.,  will keep telling a user that he has been
infected.  (He will never know "good" from "bad" if both propogate over
the same means.) Also, if the programmer can write a "good" virus to
escape the view of common virus detectors, then virus writers also have
the same technology.

>Greenberg, you forget the Shareware protection (one of many).  "Send usyour
>money or else it won't work after a while..."  Anyone know how many    es of
>piece Shareware have trojan horses?

Some shareware out there has a strange kind of protection on it so that
you don't have a trojan horse if you don't pay.  I've seen programs
that let you install them the first time around; and they monitor the
date from installation.  After a few months, or a year, they won't run
giving you a message that you need to buy the software if you are
really interested in it.  Now for any computer literate person, it is
easy to hack out the date stamp, or anything to those means to bypass
this protection. But from the company's side, no "trojan horse" is
released, and the average user is rightfully oblijed to buy the package
since s/he has had a long enough trial period.

David Bader
DAB3@LEHIGH
=========================================================================
Date:         Thu, 8 Sep 88 17:33:00 CST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         conni annable <ANNABLE@UTHSCSA>
Subject:      non-existent Viruses

I've just been looking through a friends catalog from a company that sells
disks full of public domain/shareware programs.  Page 3 of this catalog is
titled "Topic:  VIRUSES" in which they claim "a couple of national magazines
first thought up the concept of MS-DOS viruses" and hmmm... I'll quote
this paragraph entirely:

>>> Simply put, there is no such thing as a virus. There never has been.
>>> Period. It is a "Modern Urban Legend". The same as the $50 Corvette,
>>> alligators in the New York sewers, and all the others.

They go on to say that they can only speak for the MS-DOS microcomputer
world and that they have tried unsuccessfully to track down some of the
rumors they have heard. They point to PC Magazine and PC World as very
active in 'spreading these stories' and wonder if they are doing that
to sell magazines or software (at "up to $900").

They do admit that Trojans exist but state that they are 'Very Rare'.

Obviously, they have a great interest in getting folks to continue to
use public domain programs - after all that's their business.

Gee folks - think of all the time we've wasted thinking/writing/reading
about this non-existent threat! do you think we should dissolve the list?
(she said with tongue firmly in cheek...)

On another page this catalog refers to a newsletter from the DENVER PC
BOARDWATCH as having "an excellent two-page article debunking the virus
scare". Have any of you seen this? I can't tell when it was - they say
"just last month" but give no indication when this was written other than a
1988 copyright. If someone has seen this article, could you summarize it
please?

Thoroughly disgusted (having recently been bitten),
conni


=========================================================================
Date:         Thu, 8 Sep 88 21:54:00 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         KEENAN@UNCAMULT
Subject:      Re: Legality
In-Reply-To:  Message of 8 Sep 88 07:32 MDT from "Jim Marks"

I'm not a lawyer either, Jim, but a few things that would certainly be
relevant:

Did the company KNOW about the virus?  It is a basic legal principle in
most civilized countries that you need to form the *mens rea* (guilty
mind) to be guilty of a criminal offence.  In civil actions for
negligence, again the company must be shown to have some reasonable
grounds to suspect the existence of a virus.  closest analogy i can
think of is Johnson and Johnson might have been sued successfully for
continuing to sell Tylenol in the face of a clear and well known danger.
(They took it off the market for a while, of course.)

As for the structural engineering question, we just had such a case in
Vancouver, a brand new parking structure collapsed injuring dozens of
people.  The association of professional engineers temporarily lifted
the licenses of those responsible pending investigation.  IF they were
using computers AND KNEW OF SOME FLAWS they would be clearly derelict in
their duties.  (I worked for the company that designed a rather famous
110 story building in New York City and we did indeed find some design
mistakes that needed correcting before construction.)  IF the engineers
had every reason to trust the programs (they relied of them for a long
time in the course of business) then it might indeed bounce back to the
software company's lap, and it would depend how knowledgeable they were
about potential flaws/shortcomings etc.

I agree that the shrink wrap disclaimers are worth the cardboard they're
printed on (if that...)
=========================================================================
Date:         Thu, 8 Sep 88 22:20:00 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Bernie <BSWIESER@UNCAMULT>
Subject:      Re: good viruses/bad viruses
In-Reply-To:  Message of 8 Sep 88 11:02 MDT from "me! Jefferson Ogata"

Sorry if its all been said before.  I just think it is too much work to
install a vaccine program and have it execute every boot or to have to
do spot checks on all my disks for something which has only hit me once
(and on the City's machines, not my own).  Vague as always.  Me.
=========================================================================
Date:         Fri, 9 Sep 88 08:35:54 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David M. Chess" <CHESS@YKTVMV>
Subject:      good viruses/bad viruses

I take it that these "good viruses" would at least tell the user
that they were there, and preferably ask his permission to proceed?
Otherwise, *whatever* it's doing, I'd consider it Very Antisocial
for a program of whatever ilk to take it upon itself to do something
that I never asked it to do, because someone somewhere once decided
that it'd be "for my own good".   Rank paternalism!

Viruses are immune from infection?   In what sense?   If "good"
viruses became common, I'm sure someone would write a "bad"
virus to infect them.  It should be no more technically
challenging than writing a virus to infect PC-DOS EXE files.

Pardon the belligerence!
DC

(Affiliation given for identification purposes only)
=========================================================================
Date:         Fri, 9 Sep 88 08:55:42 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         portal!cup.portal.com![e-mail]
Subject:      Re: Virus Legislation


     Daniel M. Greenberg writes:

>Many viruses are contracted by people that download unknown software
>from bulletin boards.  If they didn't down-load it, it wouldn't have
>propagated in their system.  Every time you download something- you
>take a risk that it has a nasty virus.  If you go to a store nd buy
>a program, you can expect it to be "clean".

     Not so.  The MacMag virus was (accidentally) distributed with
Freehand, an Aldus product.

     Also, what about mail-order? what about those little packages
that you see advertised in computer magazines that were probably put
together by some freelancer in his home office?  Who's to say he
hasn't been infected and is distributing infected copies of his
software?

     If one takes this 'trusted sources' argument to its logical
conclusion, we're all going to have to go back to programming by front
panel switches and programming our own code and no one elses.

     Even a reasonably large company such as Aldus can get burned.


Dan Hankins

     These opinions are my own and are not for sale.  However, they
     may be rented or leased at reasonable rates.

=========================================================================
Date:         Fri, 9 Sep 88 11:21:04 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         OJA@NCCIBM1

Re: The Burleson Case in Texas

1. The computer sabotage, to the best of my knowledge, was not a
virus, but a Trojan that would monthly wipe out commissions records
from the computer accounting database. (It seems that various news-
paper reporters have trouble discerning between the varieties of
malicious programs. This, unfortunately, includes writers for
computer user group newsletters in many cases.)

2. Since I am preparing a future article on this case (mainly for
non-profit computer user groups newsletters), are there any
VIRUS-L participants in the Texas area who can help me by sending
news clipps and other info about the case? (I am also working on getting
a FOIA request in to the Dallas office of the FBI. But that's going to
take some time.)

Re: My comment about computer newsletter writers above....

I am also a writer for computer user group newsletters. Itin
writing on a more serious level about viruses that I have learned
many of the pitfalls about journalism and research. Some of my
collegues, who are quite competant in writing about software and
hardware, stummble when it comes to dealing with events in the
news. Unlike having software or hardware before you to examine, news is
lot trickier. First, the source has to be examined. Second, confirmation
has to be sought. Third, discretion is need to know whether everything
that passes one's eyes is to be published. Fourth, such information
gathering has a relational aspect, one has to deal with people not
disks or hawrdware. Discernment is crucial.

Some of the newsletter misinformation that I have run into over the
past year include...

* The claim that Donald Burleson was the writer of the SCORES virus.
  In talking with the author of the article, I found that he used a
  newspaper report and jumped to conclusions based upon the Texas
  location and Federal involment in the case.

* A Texas users group newsletter article about "viruses" having an
  interesting classification of "benign", "malignant", and
  "contagious" (!!!!) Examination of the article showed that the
  author was lumping together Trojans and viruses, so the "contagious
  viruses were really the viruses and the other categories were forms
  of Trojans.

* Many articles claiming that viruses don't exist except as a ploy
  by "anti-virus" software distributors to sell their wares.

The way these claims themselves get replicated can be considered a
"viral mode" - "information viruses" <GRIN, IS JOKE.> Actually, it
the old case of misinformation at work.

Re: If one get an infected commercial software package, can the person
sue the company?

In the USA and many other countries - yes. As a civil tort case or
possibly a class action suit, it is possible. So far, I know of no
virus liability case that has gone to court. There has been much
talk of virus lawsuits after the ALDUS FREEHAND incident, but no
further news.

Re: VIRUS-L Subscription and messages to me....

I have noticed a problem with the storage of BITNET transmissions
at my installation. Using the spool display facilty on the TSO
MVS system here, I noticed that the files often get purged with
no apparant pattern. With that and time constrictions, a method of
coping will be to unsubscribe to this list and to weekly get the
logs from LISTSERV. I can still receive promptly any messages sent to
me. Also if anybody has sent messages directly to me and has not
gotten a response, please resend, the message(s) may have been wiped
out. Thank you.
=========================================================================
Date:         Fri, 9 Sep 88 17:41:05 +0200
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Y. Radai" <RADAI1@HBUNOS>
Subject:      Re: CRC vs. encryption schemes

  I haven't noticed any reply from Jerry Leichter to my posting of Sept. 2.
Anyway, a number of people have sent me personal messages asking almost iden-
tical questions, so I thought I might as well make my answers public in case any
others on the list have similar questions but didn't dare to ask.  (Btw, Joseph,
my reply to you came back with the message "CUNYVM.CUNY.EDU unable to connect
for 3 days to host", so please accept this as if it were a personal reply to
you.)

  The questions were:  (1) What are the three "loopholes" in checksum programs
which I mentioned in my postings of Aug. 29 and Sept. 2?  (2) What is the pro-
gram I have been referring to which blocks all three loopholes?

  First of all, despite what I wrote, it's not so clear that the number of LHs
(loopholes) is 3; it all depends on how you count them.  In two cases I was
counting two similar LHs as one; maybe it would be more reasonable to separate
them and then there'd be 5.  Anyway, I'm in the process of preparing a rather
long document on the use of CPs (checksum programs) for detecting viral infec-
tion, and I explain all but one of the LHs there.  It should be finished in a
few weeks.  Roughly, it can be divided into the following sections:
  1. An introduction to CPs.
  2. LHs in CPs.
  3. Limitations of (all) CPs
  4. Criteria for comparison of CPs.
  5. A partial comparison of 16 CPs with respect to almost 30 criteria ("par-
tial" in that I have very little information at present on most of the CPs).

  I'm not sure what the best way of presenting this information is when it's fi-
nished.  (About a month ago I sent out a draft version of my document to three
people for constructive criticism, and one of them suggested that it would be
an appropriate subject for a lecture at the October conference.  But that sort
of thing is obviously not in my hands.)

  The program I was referring to is an Israeli product called VirAlarm (not to
be confused with Lasertrieve's product of the same name).  It sells for $50, and
you can get a good idea of its relative merits from the last section of my docu-
ment.  My conclusion is that it's far better than any of the other programs in
my possession.  Obviously there may be products which I have not seen which are
as good or better than VirAlarm in some respects, although I doubt this as far
as LHs are concerned.  I understand from the authors that VirAlarm is to be
marketed in the U.S. in the near future.

  In any case, I have absolutely no commercial interest in the product.  (Actu-
ally, this "disclaimer" isn't enough in my case, since I'm in frequent contact
with one of the authors, and someone might suspect that I'm trying to get in a
plug for him.  So let me emphasize that I'm being as objective as I can when I
say that I genuinely believe it to be an excellent product.)

  By the way, VirAlarm was the subject of a bet on Israeli television a few
months ago.  The authors claimed it could detect *any* virus infection, while a
Tel Aviv software house claimed it couldn't.  Anyone who's interested in a re-
port on the outcome and details can get it from the Risks Digest, Vol. 6, No.
93, or by writing to me.

                                           Y. Radai
                                           Hebrew Univ. of Jersualem
=========================================================================
Date:         Fri, 9 Sep 88 11:16:07 PDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments:     Warning -- RSCS tag indicates an origin of KLING@UCIVMSA
From:         MESSAGE AGENT <KLING@UCI>
Subject:      Re: non-existent Viruses


Dear Virus Discussion List,
        This is an automatic reply.  Feel free to send additional
mail, as only this one notice will be generated.  The following
is a prerecorded message, sent for Rob Kling


I am  out of town for about a week, on the East Coast.

I will be back around Sept 15-17.

If you need to leave a message for me by phone, please call
714-856-5955 and leave a message with a secretary,.....

or call 714-786-0873 to leave a longer message with
my house sitter or on my answering machine.

Rob Kling
=========================================================================
Date:         Fri, 9 Sep 88 15:10:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Glen Matthews <CCGM@MCGILLM>
Subject:      Good vs. Bad Virus: "Mutations"

With respect to "mutation" of a virus, I would suggest that a correctly
functioning virus would not do that. Certainly, testing should result in
any such undesirable behaviour being corrected.

However, remember the environments that this "good" virus might be
injected into. My programs, for example, are not guaranteed to be free
of bugs every time I run them, especially the first time. If a correctly
functioning "good" virus infects one of these programs, it is just
conceivable that *my* program accidentally modifies the virus prior to
propagation: thus, a "mutation".

Lest this sound terribly unlikely, recollect the WORM article in CACM.
The authors describe one of their experiences with a worm which
apparently became altered in execution. My memory may fail me here, but
I don't believe that hardware error was advanced as the cause (the
authors could not have known exactly, anyway).

Basically, when the issue of so-called "good" viri comes up, it behooves
us to remember which road is paved with good intentions. Precisely
because we cannot predict the eventual environment that a virus might
be found in, I think that we should be cautious about releasing a virus
even though that virus will solve all of our thorny problems for us.
And by "cautious", I don't mean TESTING the virus; I mean having a
*VERY* clear idea of the target population, as well as having escape
hatches within to shut down the virus if required. And even these
measures might not be sufficient to justify the release of a so-called
"good" virus.

          Glen Matthews
          McGill University
=========================================================================
Date:         Sat, 10 Sep 88 16:34:16 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      Re: Easiest OS to infect
In-Reply-To:  <QUCDN.X400GATE:LVAbjk4X*>

>In reply to the comment that bigger is easier to infect  I beg to differ.
>
>Operating systems with layered architectures and rich file support are
>easier to infect.  They may also be easier to defend with.  There is an
>easy to use suite of public domain and sharware tools available.
>
>I can only hope th

So what do we mean by "layered architectures" and "rich file support"?
As a relative neophyte in operating systems I would like to know.
Does DOS have these features?

                                       __________________________________
                                      |                                  |
David Slonosky/QueensU/CA,"",CA       |         Know thyself?            |
<SLONOSKY@QUCDN>                      |  If I knew myself, I'd run away. |
                                      |__________________________________|
=========================================================================
Date:         Sun, 11 Sep 88 15:46:46 MEZ
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Konrad Neuwirth <A4422DAE@AWIUNI11>
Subject:      Re: Different Operating Systems
In-Reply-To:  Message of Wed,
              7 Sep 88 20:28:01 EDT from <[e-mail]>

hi,
  as an amiga user, too, and having been affected i can tell you something
about the amiga viruses. A nice guy from switzerland ( of SCA) wrote a
virus on the amiga, just to proof it is possible. Now there exist a lot
of mutations of this virus, the most commonly know the byte-bandid virus.
To understand the amiga viruses, it is necesary to know a bit about the
amiga OS. It uses, as most machines do, the first track as a boot track,
but it doesn't write too much into it, so there is a goos space for a virus.
As the amiga is a multitasking machine, it is not too hard to make up a
virus, as it just has to be a task, which doesn't have a window. The
amiga OS is not a too good Multitasking enviroment, as it has almost
no ways to protect one task from another. You certainly can imagine what
that does mean for a virus. The SCA virus is, thank god, not a destructive
one, but it is still enough. But the author did make a good thing in the
virus ( if you can say good things about viri ;-)), he built in a self
destruction feature. There also exist programs to protect the machine, and
even some are small tasks chacking each inserted disk for a nonstandart
boot block. I personally use VirusX, which is such a program.
I don't know more about the other machines


                               SIGNED, AS ALWAYS
                                     I  /I  +----
                                     I / I  +--
                                     I    I  +----
 "SORRY FOR LIVING, I WILL NEVER DO IT AGAIN"
                    KONRAD NEUWIRTH (A4422DAE AT AWIUNI11) (KONRAD ON RELAY)
=========================================================================
Date:         Sun, 11 Sep 88 17:43:00 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments:     <Parser> W: Field "Resent-Date:/Date:" duplicated. Last occurence
              was retained.
Comments:     <Parser> W: Field "Resent-Message-ID:/Message-ID:" duplicated.
              Last occurence was retained.
Comments:     <Parser> W: Field "Resent-To:/To:" duplicated. Last occurence was
              retained.
Comments:     <Parser> W: Field "Resent-From:/From:" duplicated. Last occurence
              was retained.
Comments:     <Parser> W: Field "RESENT-FROM:" duplicated. Last occurence was
              retained.
Comments:     Resent-From: Bernie' <[e-mail]>
Comments:     Originally-From: Glen Matthews <[e-mail]>
From:         Bernie' <BSWIESER@UNCAMULT>

In-Reply-To: In reply to your message of FRI 09 SEP 1988 18:51:00 EDT

Mike <[e-mail]> commented, re "mutations",

   > ... in the chance of a bug (mutation) code is more likely
   > to crash or hang than to follow some destructive path.

I'd agree. However, random zapping of an execuing program doesn't
necessarily involve the zapping of code; data required by the "good"
virus may be the component that is accidentally modified.

In my work with systems, I've seen cases where instructions have been
modified such that the system continues to function without a hard
failure. And let me point out the case in CACM again (I'm at home now,
so let me quote from the article):

   "... We have speculated that a copy of the program (the worm)
    became corrupted at some point in its migration, so that the
    initialization code would not run properly ..."

Coupled with their environment, the unexpected result of an uncontrolled
worm became a reality. Note that the programs involved do not have to
function correctly or anything; as long as it "reproduces", a corrupted
virus is dangerous.

To stretch the biological analogy perhaps to the breaking point, recall
that although individual occurances of mutations might be recall, simply
multiplying the probability of their occurance by the number of possible
PCs wherein they can occur can give rise to an unexpectedly large
number.

I don't want to over-emphasis this; in fact, I'd guess that this threat
is probably relatively minor. But thinking that "good" viri can only
generate "good" effects is like thinking that guns in the hands of
policement ("good guns") can only generate "good" effects.

              Glen Matthews
=========================================================================
Date:         Mon, 12 Sep 88 00:04:00 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         LYPOWY@UNCAMULT
Subject:      Infecting "Good" Viruses

Bernie, since a virus usually just prepends itself to an existing
"program" file, is it not possible that a good virus could have a "bad"
virus prepended to it?  Then, when this file is executed, the bad virus
would have control, then relinquish its control to the good virus (if
that is in its game plan), and then the "good" virus would relinquish
control to the original program.

Loren ==> Is it possible to get a copy of the magazine that you are
publishing for the upcoming virus conference??!!

                              Greg Lypowy
=========================================================================
Date:         Mon, 12 Sep 88 02:23:25 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         me! Jefferson Ogata <OGATA@UMDD>
Subject:      virus mutations

>                               But thinking that "good" viri can only
> generate "good" effects is like thinking that guns in the hands of
> policement ("good guns") can only generate "good" effects.

Good God; I hope nobody suggested either of those things! :-)

- Jeff Ogata
=========================================================================
Date:         Mon, 12 Sep 88 07:56:33 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject:      Forwarded article on virus existance, from RISKS


     Here's a somewhat amusing story that was recently posted to RISKS:


Date:     Wed, 07 Sep 88 17:30:40 EDT
From: Mark Moore <[e-mail]>
Subject:  "Viruses Don't Exist" and the Marconi Mysteries...

I received one of those info-card packs (I forget from whom) as a result
of having my name and address sold by Dr. Dobb's.  I filled out a few of the
cards and received a catalog from Public Brand Software, which is a shareware/
freeware clearing house based in Indianapolis, IN.

Here are a few quotes on from the third page of their catalog entitled
'Topic: VIRUSES'

  'It seems like a couple of national magazines first thought up the concept
  of MS-DOS viruses.  Unfortunately, a lot of people read these magazines and
  believe everything that they read.  But let's get a couple of definitions
  clear first.

    virus, n. 1. a purposely destructive computer program that can
      propagate itself by modifying other computer programs (such
      as COMMAND.COM) to make them destructive.  2. a destructive
      myth perpetrated to sell a product and/or fill editorial
      space.'

The article goes on to claim that viruses are myths akin to friend-of-a-friend
stories; popular magazines are perpetuating the myths to have something
sensational to print; engineers are doing the same in order to sell vaccines.
They claim that they've searched high and low and can find no such thing as a
virus.  'Simply put, there is no such thing as a virus.  There never has been.
Period.'

Sounds like a dangerous attitude to me.

     [Ken - Sounds like a case of foot-in-mouth to me...]

Kenneth R. van Wyk                   Calvin: Ever consider the end of the
User Services Senior Consultant        world as we know it?
Lehigh University Computing Center   Hobbes: You mean nuclear war?
Internet: <[e-mail]> Calvin: I think Mom was referring to if I
BITNET:   <LUKEN@LEHIIBM1>             let the air out of the car tires again.
=========================================================================
Date:         Mon, 12 Sep 88 09:16:31 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ken van Wyk <[e-mail]>
Subject:      Virus research paper by ex-Lehigh student

The following paper was sent to me by Stephen Kiel, a graduate (and
ex-student employee) of Lehigh University.  The paper was done while
Steve was finishing up work on a Masters degree in Electrical
Engineering at Georgia Tech.  VIRUS-L readers may recognize some of
the quotes which Steve used as having been taken from VIRUS-L.  Many
thanks, Steve, and best of luck in recuperating from your 1200 mile
bicycle ride home to NJ!  :-)  Steve no longer has network access since
leaving Georgia, but hopes to be rejoining VIRUS-L upon taking up his
new job at Bell Labs.

Ken

--------------------------------------------------------------------------

             THE INFECTION OF PC COMPATIBLE COMPUTERS


                                  Stephen E. Kiel
                                  Raymond K. Lee
                                  Georgia Institute of Technology
                                  Summer Quarter 1988

INTRODUCTION

         The recent  publicity over computer viruses has produced
mixed reactions and much confusion inside, as well as outside, of
the computing industry.  The conflicting opinions are caused either
by a misunderstanding of what viruses are or a lack of
understanding of their potential problems.  This paper answers
those questions and in addition, gives a description of currently
suggested methods for IBM PC's and compatibles for detecting,
preventing, and eliminating viruses.  A highly technical discussion
is not the objective, but rather a broad overview is given along
with sources of additional information and assistance.


THE BEGINNING

         On November 3, 1983, an idea was conceived of by Fred
Cohen as an experiment to be presented at a weekly seminar on
computer security [1].  The idea was simple enough:  design a
computer program that could modify other programs to include a
possibly evolved copy of itself.  This evolved copy would then
modify other programs and thus continue the propagation and
evolution.  The program could easily be spread by unknowing users
throughout a computer system or network.

         It only took eight hours of expert work on a heavily
loaded VAX 11/750 to complete the first of such programs and
prepare it for demonstration.  The program was inserted into the
beginning of a new program on the system called 'vd,' which
displayed Unix structures graphically.  A new program was chosen so
that details of its operation and its performance characteristics
would be unknown.  Users were introduced to vd via the system
bulletin board.

         The program inside of vd used the authorizations of every
user using it to infect their programs.  In all of the experiments,
the program that was initially inserted into vd was granted all
system rights in under an hour.  The shortest time was under five
minutes, with the average time under 30 minutes.  Even people who
knew that the experiments were taking place were unable to defend
themselves.  Once the surprising results of the experiments were
announced, the administrators of the VAX 11/750 decided that no
further computer experiments would be performed on their system.
Precautions were taken to keep the experiment under control.  No
damage was done and only reports were sent back on the program's
progress.  Also, traces were generated to insure that the program
could not spread without detection.  All files were purged of the
program after the experiment was completed.  It is unfortunate that
an apparent fear reaction on the part of the system administrators
prohibited any further testing.


DEFINING A VIRUS

         A name for programs exhibiting the behavior described
above was thought of by Len Adleman:  'viruses.'  A computer virus
can generally be defined as a program which hides in computer
systems, usually in larger programs, whose mission is to replicate
and spread until the occurrence of some designated event.  When
this event takes place, the program can then perform some action
specified by its creator.  The term 'virus' is very appropriate
since computer viruses (here after referred to as simply 'viruses')
behave much like their biological counterparts.

         Once in a computer system, a virus can remain quiet for an
incubation and contagion period, during which it infects other
files.  After some prespecified event, such as a period of time or
a number of infections, the virus can come to life and begin an
attack.  All the while, the offspring of the virus are infecting
other files and systems, also waiting to be triggered to attack.

         The software that controls the computer and the devices
connected to it is known as the DOS, an acronym for disk operating
system.  DOS commands are the core of the operating system and
instruct the computer to start, stop, or continue an operation.
The most popular DOS for IBM PC compatible computers is Microsoft
Corporation's MS-DOS.

         Personal computer viruses typically infect three special
MS-DOS files:  IBMBIO.COM, IBMSYS.COM, and COMMAND.COM.  These
files are found on every system disk and become part of memory each
time the operating system is loaded into the computer.  The system
files IBMBIO.COM and IBMSYS.COM are hidden and read-only and are
not easily infected.  The COMMAND.COM file, which is the default
command processor of MS-DOS, is both visible and modifiable.  A
number of viruses have been discovered which infect this file.
These three files are copied to other disks and run on other
machines often enough that a virus in any of these files can spread
very quickly.

         The action performed by viruses will vary.  It could be
simply the flashing of a harmless message on the screen.  A virus
in Aldus Publishing's FreeHand, a graphics program for the
Macintosh, printed the message, "We would like to take this
opportunity to convey our universal message of peace to all
Macintosh users around the world" [2].  The company had to recall
about 5,000 infected packages.  Unfortunately, all viral behavior
is not benign like this message printing or the simple infection
tracing found in the experiment discussed in the opening paragraphs
of this paper.  There have even been reports of viruses which can
slightly modify spreadsheets and other data [3].

         Viruses have been found which reformat hard disks and
destroy data.  The destructive behavior is only limited to the
warped imagination of its creator.  Because of the hidden dangers
involved, apparently safe software packages carrying such viruses
have become known as "Trojan Horses."  A viral outbreak of this
sort took place last fall in the microcomputer labs at Lehigh
University in Bethlehem, Pa. [4].  This particular outbreak,
described below, generated a lot of publicity and caused both
corporations and colleges alike to become concerned about the
potential damage that viruses can inflict.


THE LEHIGH VIRUS

         The Lehigh virus was typical of many other viruses.  It
sat in the COMMAND.COM file and was thus loaded into the computer
whenever it was booted.  The virus hid inside this file in a
temporary storage space called the stack space.  After infecting
the same file on a number of other disks, the virus would wipe out
all data and program files on the disk it was on.  Backup copies
were similarly infected, some users were attacked more than once.

         Once the outbreak had come to light, work began
immediately to identify what was happening and to find a cure.
Fortunately, the virus' creator made a mistake:  the date on the
COMMAND.COM file was altered by the infection.  (It is relatively
simple to keep the date from changing, so the absence of a changed
file date does not guarantee that a file is virus-free.)

         Upon examination of the file, the contaminated stack space
was discovered.  Since this space is normally all zeros, student
lab consultants wrote a simple program that looked at the stack
space and wrote zeros over any code that was present.  The virus
was then erased from approximately 600 disks.

         If it was not for the creator's date mistake, it would
have taken much longer for the Lehigh Computing Center to kill its
virus.  It is doubtful that any new viruses that crop up will make
a similar mistake.  As everything else related to computers
increases in complexity, so will viruses.


SIZING UP THE PROBLEM

         It is unknown exactly how many disks and computer systems
are infected in the world.  Some experts and officials are trying
to keep track of the world's viruses by documenting their
characteristics and occurances.

         For example, four versions of the Israeli virus and seven
versions of the Brain virus [5] have been found.  The Israeli virus
was supposed to do some kind of damage on May 13, 1988, the fortieth
anniversary of the founding of Israel.  The Brain virus was originally
written to warn would-be software pirates of a software package for
physicians written by Basit Farooq Alvi, a 19-year-old from Pakistan.
The Brain has since evolved to data destruction.


VIRUS HYPE

         Fueling the scare is indeed a problem and has led to what
has become known as the "Virus Hype."  The press and media has been
notorious for spreading rumors and partial truths about viruses.
Besides causing undue panic and fear amongst computer users, the
virus writer is getting notoriety and fame.  This is shown in a
statement from Stephen D. Morrison, a student from the University
of Manitoba.  When asked about the future of viruses, he responded
with the following:  "The scenario could be a mad-hacker, plugging
away at a keyboard in the back of a dimly lit office, creating a
virus like no virus ever seen before."  This view angers
professionals in the computing field.

         Ivars Balkits, an official from Computing Services at the
University of California - Davis, stated, "Depicting the virus
writer as a gothic/romantic figure (like pirates have been, like
gangsters have been, like gang members now are) contributes to the
problem.  Continuing to fictionalize the virus writer as a mad
scientist, a Doctor Frankenstein whose genius gives us a secret
thrill, whose lawlessness challenges us, is just the wrong way to
go."

         Another approach to stopping the hype and actually
tracking the viruses is "The Dirty Dozen" maintained by Eric
Newhouse [6].  This is a file, originally started by Tom Neff,
which lists unlawfully copied or modified programs that have
appeared on various IBM bulletin boards across the country.
Newhouse hopes that this list will act as a "clearing-house" for
the latest examples of "bogusware," i.e. software that is damaging
to one or more parties.  Currently there are almost 50 destructive
programs listed.

         In addition to the list of bad software, the Dirty Dozen
contains definitions of viruses and other destructive programs,
instructions on what to do if a virus causes damage to a system,
and a glossary of many of the confusing acronyms and terms used in
the computer field.  A list of addresses to send additions and
corrections to the Dirty Dozen, along with comments to Eric
Newhouse, is included in APPENDIX 1.   Copies of the Dirty Dozen
can also be obtained from the bulletin boards in the list mentioned
above, as well as from many different electronic bulletin boards
across the country.


DETECTION

         Fred Cohen, now a member of the Electrical Engineering
faculty at the University of Cincinnati, stated in a lecture at the
IBM Watson Research Laboratory in Hawthorne, NY, that there are
three ways to detect a virus:  by its appearance, by its behavior,
or by the changes it causes.  Detection by appearance is
undecidable since all viruses do not "look" alike.  It is extremely
difficult to look at a good-sized program written in assembly
language and tell what it does.  With an executable program, it is
nearly impossible.

         Detection by behavior involves examining programs as they
are executing and is also not very promising.  Besides being
disruptive by slowing down execution times, it produces too many
false positives and false negatives.  Initially, viruses were
caught by having a monitor program watch for certain internal MS-
DOS and BIOS system calls which are normally used to access system
hardware, but now that is no longer the case.

         BIOS is an acronym for basic input/output services.  Since
hardware varies from machine to machine, the BIOS is used to
abstract the operating system from the specific hardware it's
running on.  The BIOS directly controls all of the input/output
devices, such as the monitor and the disk drives, according to
instructions received from MS-DOS or an executing program.

         Unfortunately, viruses can bypass MS-DOS and BIOS system
calls.   It is relatively simple to go to a computer store and
purchase literature that describes where MS-DOS and the BIOS keep
the information they need about a disk, and also tells what port
addresses do what on a PC.  In order to insure compatibility
between different brands of PC's, every computer manufacturer has
to use the same BIOS data areas and the same port addresses.  It is
no mystery to find out exactly what a program has to do to get its
hands on the hardware.

         Detection by change is easy to forge and can be very
costly.  Early viruses were found to simply append themselves onto
files and thus change the file size or possibly change the file
date, as in the Lehigh virus, viruses have become much more
elusive.  Existing files can have viruses implanted inside without
changing their file length or modification date.  It is also not
very beneficial to use an erased hard disk as an indicator of viral
presence.


PREVENTION STRATEGIES

         "Prevention is the best medicine" is a phrase heard many
times before, but this small advice is very true in the case
against viruses.  The key is education.  There must be an awareness
among users from the hobbyist to system managers of the potential
dangers of viruses.  Obviously, paranoia is not the goal but a
general understanding must be achieved.

         With today's ever growing dependence on computers,
ignorance will cost a heavy price, if it has not already.
Therefore, steps must be taken to curtail the likelihood of viral
destruction.  Governmental legislation needed is already in
progress:  a House bill, the Computer Virus Eradication Act of
1988, was introduced in June that will make infesting computers
with viruses a federal crime.  A copy of this pending bill is in
APPENDIX 2.  Several other legislative acts have also been
proposed.  Currently, 48 states have computer crime laws.

         Fortunately, there are some guidelines that, if followed,
will go a long way in keeping one's computer system virus-free.  Of
course, these guidelines are only as effective as the extent to
which users are willing to implement them.  These guidelines are
divided into three areas - protection of diskettes, protection for
the computer, and protection of systems interconnected by a local
area network (LAN).


DISK PROTECTION

         The first thing to do is not to use the original or master
diskettes to execute the programs.  Copies of all the original
source disks should be made and used instead.  The originals should
then be stored in a safe place, out of sight.  Although it is
inconvenient, it is better to have the storage place far away from
the computer or system itself.  If there ever is any question as to
the integrity of one of these copied files or disks, it can always
be compared against the safely stored-away master copy.

         It is a very good idea to start using the write/protect
tabs that so often get thrown away.  These little stickers, usually
black or aluminum colored gummed paper tags, can really save the
day when it comes to inadvertent writes.  Once a tab is in place,
it is impossible for the computer to write on the disk.

         Besides being found on every system disk, the COMMAND.COM
file is also a favorite hiding place for viruses.  This file, as
well as most others, can and should be made read-only without
affecting its use.  This can be easily done with the MS-DOS
"ATTRIB.COM" program.  Many other utility programs, such as those
listed following the paper in APPENDIX 3, can also accomplish this
task.


COMPUTER PROTECTION

         The goal of virus protection can only be accomplished by
limiting computer access.  This strategy is simple:  keep the
computer "clean" by keeping the virus out.  First and foremost,
only tested software should be used.  Also, a computer should never
be booted up with an unfamiliar disk.  This means that a user must
be especially cautious and extremely careful with public-domain or
shareware programs.  Most viruses have a hibernation or incubation
period, so even a seemingly good disk from a friend, co-worker, or
other source can be infected.

         To protect a computer's existing files, it is advisable to
establish a good method for backing up files on a regular basis.
One strategy is to do incremental backups three times a week and
perform a complete backup every two months.  File attribute (FAT)
tables can and should also be backed up.  The intervals between
backups should correspond to the amount of activity on the
computer.

         When the computer is not in use, turn it off and lock it
up.  When a machine is left turned on and unattended, there is no
way to know what has been installed or run on it while it was
unsupervised.  This implies that a computer should never be used
unless the user personally boots it up.  As far as locks are
concerned, it is usually negligible to have a key lock installed.
Software locks on PC's are easy to bypass and should not be
trusted.


LANS AND VIRUSES

         Beside interconnecting users, LAN's can provide a
excellent route of propagation for viruses.  In response to their
initial virus attack, the computing center at Lehigh University has
been taking many steps to reduce the possibilities of any new
outbreaks.  According to Kenneth van Wyk, a senior consultant at
Lehigh, additional precautions to those mentioned above should be
taken.  The procedures in effect at Lehigh University's PC
laboratories, which can also be applied to other distributed
computing environments, are the following:

         1)   All public microcomputers contain dual floppy drives
              and are connected to LANs (Novell on 3COM boards).
              The hard disks were removed.
         2)   All boot disks are notchless and contain nothing
              other than the operating system boot files and the
              Novell software needed for the LAN.
         3)   All Novell hard disks on the file servers are read-
              only, with the exception of a "scratch" area where
              users can place their temporary files.
         4)   The "scratch" areas get erased periodically by
              Lehigh's student employees.
         5)   Users logging into the LAN are not automatically
              placed in the scratch directory.


VACCINES

         With the growing publicity and concern over viruses, there
has been a sudden upspring of so called "vaccines".  It may even
seem that the number of these programs are quickly catching up to
the number of known viruses.  Keep in mind, however, that none of
these programs are 100% cures, and that many take a different
approach in trying to solve the same problem.

         Probably the best attitude to take regarding these
"vaccines" is the that of the Paul Mace Software Company -
"Understand, the people who make these (viruses) are clever and we
haven't seen their worst.  We're clever too, and will keep on
improving the vaccine."   Several of the software/hardware products
of this nature that are designed for personal computer use at home
and in industry are listed in APPENDIX 4.


AFTER THE ATTACK

         Even though precautions are taken, the worst sometimes
happens:  a virus evades the lines of defense and wreaks havoc.
Even if a hard disk does manage to crash, regardless of whether it
was virus-induced or not, all is not necessarily lost.  Some
investment of time may be needed, but the data can usually be
recovered.

         There is no better remedy for a crash of any kind than a
recent backup.  Unfortunately, if the virus was backed up along
with the rest of the disk, restoring the backup contents may bring
the virus back to life.  If this happens and another crash occurs
from the restoration, it is time to do either a lot of detective
work or seek professional help.

         Once a crash has occurred, the first step is to remain
calm.  The strong urge to shout and destroy nearby office furniture
has to be suppressed.  After this is done, the damage must be
surveyed.  The crash is probably a result of the virus doing one of
the following:
         1)  Formatting the disk
         2)  Scrambling the FAT (File Attribute) table
         3)  Erasing files
         4)  Corrupting the disk's boot sector
The amount of data that can be recovered depends on the cause of
the crash.

         At this point if you do not know what you are doing, it is
well worth the time and money to find someone who does.  Recovering
data from a crashed disk is a highly technical matter.  Further
information on the above causes and their remedies are provided in
APPENDIX 5.  Any improper attempts by an inexperienced user can
result in permanent data loss.


FURTHER INFORMATION

         One of the best ways to learn more about viruses and
related topics is through VIRUS-L, an electronic mail discussion
forum for sharing information about computer viruses.  The computer
that handles this forum is located at Lehigh University and is a
result of the need for more information about viruses after the
Lehigh outbreak.

         There are currently several hundred subscribers to the
list from academic and corporate institutions from all over the
world.  Discussions on the list include current events, virus
"sightings," practical and theoretical virus prevention methods,
and questions/answers about viruses.  The discussions on this list
are extremely informative and educational.

         The list is non-moderated and non-digested, which means
that any message sent to the forum goes out immediately to all
subscribers.  All  submissions to VIRUS-L are stored in weekly log
files which can be down-loaded for later reference.  Also, there is
a small archive of some of the public anti-virus programs which are
currently available.

         In order to get on the mailing list, a user must have
access to the BITNET network, which is possible through ARPANET,
Internet, and several other networks.  If this is the case, than
the user only has to send the message "SUB VIRUS-L <user name>" to
<[e-mail]>.  Questions and comments about VIRUS-L
can sent to the list's moderator, Kenneth van Wyk, at the addresses
listed in APPENDIX 6.


SUMMARY

         Computer viruses, like their biological counterparts, are
constantly changing.  It is impossible to predict the course that
future viruses will take.  According to William H. Murray of Ernst
& Whinney, "if you can conceive it, and if it could be done by any
other program, then it can be done by a virus."  The prevention and
protection methods discussed here are not infallible since they
will need to adapt to the dynamic nature of viruses.  This paper is
meant to serve as a useful introduction to the nature of viruses
and how they must be confronted.  If this information is
understood, the warnings heeded, and the basic precautions taken,
the probability of a virus attack should be lessened.


APPENDIX 1:  The Dirty Dozen

         Eric Newhouse, the editor of the Dirty Dozen, can be
contacted for more information at the following addresses:

         1)   The Crest RBBS/CAMS (160/50 MB), 213-471-2518,
              1200/2400.  (This is Eric Newhouse's bulletin board)

         2)   The West LA PC-STORE (50 MB), 213-559-6954,
              300/1200/2400.

         3)   Camelot PC-Board (80 MB), 213-204-6158, 300/1200/2400
              - leave E-mail to "NORMAN TEETER" and it will be
              relayed.

         4)   The Source - leave E-mail to "Doctor File Finder"
              (Mike Callahan) in IBM SIG #4 and it will be relayed.



APPENDIX 2:  The Computer Virus Eradication Act of 1988

Whoever knowingly --

         (1)  inserts into a program for a computer information or
              commands, knowing or having reason to believe that
              such information or commands will cause loss to users
              of a computer on which such program is run or to
              those who rely on information processed on such
              computer; and

         (2)  provides such program to others in circumstances in
              which those others do not know of the insertion or
              its effects;

or attempts to do so, shall, if any of such conduct affects
interstate or foreign commerce, be fined under this title or
imprisoned not more than 10 years, or both.

Entered July 14th 1988 by Mr. Wally Herger (Congressman from CA)
for himself and Mr. Bob Carr (Congressman from MI); referred to
Committee on the Judiciary.



APPENDIX 3:  Disk Utility Programs

         1)   PC-Tools, Central Point Software.  $80.

         2)   Mace+ Utilities, Paul Mace.  $100.

         3)   Advanced Norton Utilities, Peter Norton.  $150.



APPENDIX 4:  Vaccine Products

         1)   Antidote by Quaid Software, Toronto, Canada. Detects
              viruses but allows the user to correct the problem.
              $60.

         2)   C-4(Cylene-4) by InterPath Corp., Santa Clara, CA.  A
              program that resides in ROM and looks out for
              viruses. If found, computer activity halts and C-4
              warns the user.  $30.

         3)   Data Physician by Digital Dispatch Inc., Minneapolis,
              MN. Protects and remove viruses from MS-DOS based
              computers.

         4)   Disk Defender by Director Technologies Inc.,
              Evanston, IL. An add on board that will guard the
              hard disk.

         5)   Disk Watcher by RG Software Systems, Willow Grove,
              PA.  A memory resident utility that "watches" the
              disk drives to prevent accidental writes or formats.
              $80.

         6)   Dr. Panda Utilities by Panda Systems, Wilmington, DE.
              A set of programs that checks files from BBS and
              other software before letting them used.  $80.

         7)   FluShot by Byte's BIX. A free utility. Contact BYTE
              magazine or BIX for more information.  FREE.

         8)   Mace Vaccine by Paul Mace Software, Ashland, OR. It
              provides write protection for system files.  $20.

         9)   NTIVIRUS by Orion Microsystems, Quebec, Canada.
              Monitors the system files for viruses. $30.

         10)  Passcode System by Dynamics Security Inc., Cambridge,
              MA. Complete hardware software protection system.
              $200-$2000 depending the size and components needed.

         11)  Syringe,Canary,Infect by Sophco, Boulder, CO.  Three
              programs that will "quarantine" a bad disk, test and
              remove viruses.  $30.

         12)  Vaccinate by Sophco. A "milder virus" that will warn
              the user of other viruses.  $195.

         13)  Virusafe by ComNetco Inc., Bernardsville, NJ.  Checks
              the system memory for viruses then prevents them from
              being used. $250.

         14)  VirAlarm by Lasertrieve Inc., Metuchen, NJ.  Stores
              programs on CD-ROM after making sure they are virus-
              free.

         15)  Virus Implant Protection by LeeMah DataCom Security
              Corp., Hayward, CA.  Uses a dedicated PC to "monitor
              unauthorized activities" on other networked
              computers.

         16)  Vaccine by FoundationWare, Cleveland, OH. "5 levels"
              of protection from write-protect to checksums.  $189.



APPENDIX 5:  Recovery from a Disk Crash

         Recovering information on a formatted disk depends on the
method of formatting.  If the disk was low-level formatted, then
the contents of the files and the directories referencing them have
been over-written.  The only hope of recovery is a backup.  If the
disk was high-level formatted, then the disk contents have not been
erased and are recoverable to some degree.
         Unformatting programs have been written to reconstruct the
contents on the disk.  Since MS-DOS breaks up or fragments large
files and stores the pieces wherever there is room on the disk,
complete recovery is only possible if the unformatting programs
have a "picture" of the disk before the crash.  This picture is
generally taken by a utility accompanying the unformatting program.
Several of these programs are listed above in APPENDIX 3.
         If the FAT table has been scrambled, it can be rebuilt.
Two of the three disk utility programs listed below, Norton
Utilities and PC-Tools, include editors that allow an experienced
user to piece together a FAT table.  This is not easy and requires
a large amount of experience and a high degree of proficiency.  The
other alternative involves finding a FAT backup program and making
periodic backups.  A number of FAT backup programs are public
domain and can thus be obtained from a trusted friend or trusted
computer bulletin board.
         If files were erased and the FAT tables are still intact,
then the files may simply have to be unerased.  All three of the
disk utility programs listed in APPENDIX 3 can do this.  When a
file is erased, the first character of its name is usually changed
to a non-printable character to indicate that it is no longer a
valid directory entry.  Everything else is left intact.  Since the
contents of erased programs are over-written by newer programs, it
is best to unerase the files the most recent files first.  If this
is not done, a previously erased program may grab part of a newer
file.
         The last cause of a disk crash is when the boot sector is
either erased or formatted.  In this case, the data is still safe
on the disk, but the disk cannot be booted from.  Another system
disk in a floppy drive can be used to boot the system.  Before
proceeding any further, backup the hard disk in case any damage is
done trying to restore the disk to boot status.
         The first thing to try is running the MS-DOS "SYS.COM"
program.  This program will copy the system files from one disk to
another.  After this is done, COMMAND.COM will have to be copied to
the crashed disk using a simple "COPY" command.  Information on
this procedure is available in the MS-DOS manual.  If this does not
work, Mace+ Utilities has a function called "restore boot sector"
which should be tried.
         If all else fails, the disk should be first backed up and
then low-level reformatted.  Instructions for this procedure should
either come with the computer or are available from a computer
store.  After this is done, the MS-DOS program "FDISK.COM" be run
to prepare the disk for high-level formatting.  This formatting is
done with the DOS "FORMAT.EXE" program.  The DOS manual should be
consulted before running any of these MS-DOS commands or programs.
When everything is completed, the backup can be restored.



APPENDIX 6:  VIRUS-L

         The moderator of VIRUS-L, Kenneth van Wyk, can be
contacted for more information at the following addresses:

         1)   <[e-mail]> on Internet

         2)   <[e-mail]> on BITNET

         3)   Kenneth van Wyk
              User Services Senior Consultant
              Lehigh University Computing Center
              Bethlehem, PA  18015
              [phone]



REFERENCES

[1]      Fred Cohen, "Computer Viruses", PhD dissertation,
         University of Southern California, 1985.

[2]      P. Honan, "Beware: It's Virus Season", Personal Computing,
         July 1988, p36.

[3]      P. Karon, "The Hype Behind Computer Viruses", PC Week, May
         31, 1988, p49.

[4]      Fred Cohen, "On The Implications of Computer Viruses and
         Methods of Defense", University of Cincinnati,
         unpublished.

[5]      J. Pournelle, "Computing at Chaos Manor", BYTE, July 1988,
         pp198-200.

[6]      E. Newhouse, "The Dirty Dozen", Issue #8a, February 21,
         1988.

=========================================================================
Date:         Mon, 12 Sep 88 08:30:00 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Bernie' <BSWIESER@UNCAMULT>
Subject:      Re: Infecting "Good" Viruses
In-Reply-To:  Message of 12 Sep 88 00:04 MDT from LYPOWY

I'm thinking more of viri which hide themselves on unused sectors.
Mind, running a utility that erases all unused sectors and checks all
files against the vtoc would be just as effective?


=========================================================================
Date:         Mon, 12 Sep 88 16:26:53 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe McMahon <XRJDM@SCFVM>
Subject:      Re: hypercard virus question
In-Reply-To:  Message of Tue, 6 Sep 88 16:48:00 EDT from <$CAROL@OBERLIN>

>My colleague (bitnet address PRUSSELL@OBERLIN) asks:
>
>        Does anyone know if Hypercard stacks are capable of carrying
>        Macintsosh viruses?  Are they considered applications or data?
>
Yes. The first known Mac virus was spread via a Trojan horse HyperCard stack.
It is also possible to write self-propagating XCMDs/XFCNs which can spread
viruses. Lastly, it is possible to write viruses in HyperTalk (the HyperCard
language) which can spread only from stack to stack.

--- Joe M.
=========================================================================
Date:         Mon, 12 Sep 88 11:52:11 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         SHERK@UMDD
Subject:      Re: CRC vs. encryption schemes
In-Reply-To:  Message received on Tue, 30 Aug 88  19:00:38 EDT

Sorry if this is a bit late in the conversation but I have been on vacation.

Dr. Levine is quite right when he states that there are two distinct times
when one wants to check an application's integrity. One time is when you
recieve a program distribution and you want to check if you got a good copy.
Another time to check an application is at boot time or before you exec it.
It seems to me that these two types of checking could use two different
schemes.

Scheme 1: Software distribution.
     The publisher of a software product should publish a list of
several different CRC polynomials and their results. Say two or three.
This way, the recipiant can check his downloaded software with a couple
of CRCs. I do not beleive it is possible for two different programs
(i.e. the original and the infected) to have the same CRC number for
two different CRC polynomials.
             That is:

      if CRC( prog1, poly1) equals CRC( prog2, poly1)

      then CRC( prog1, poly2) can not equal CRC( prog2, poly2).

Scheme 2: Personal CRC
     Once you have verified that you recieved a good copy you can
then pick your own personal CRC polynomial out of the 70 million
"irreducible" polymonials. (You should pick one that is different
from the published one.) Then record the CRC number and use this
new CRC in the future.

It seems to me that this dual approach would be hard to beat.

Erik Sherk
Computer Science Center, University of Maryland.
[e-mail]
=========================================================================
Date:         Mon, 12 Sep 88 21:21:11 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         me! Jefferson Ogata <OGATA@UMDD>
Subject:      crc polynomials

It IS possible for two different programs to have the same CRC for two
different polynomials.

- Jeff Ogata
=========================================================================
Date:         Sun, 11 Sep 88 12:24:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      Re: Different Operating Systems
In-Reply-To:  Message of 7 Sep 88 20:28 EDT from "David.Slonosky%QUEENSU.CA at
              CUNYVM.CUNY.EDU"


David Slonosky asks "Are all operating systems equally vulnerable?"  Of
the examples that he calls out the answer is essentially yes.  This is
because they are all designed for personal computing and for single
state processors.  However, we when you get into multi-state systems you
begin to enjoy the opportunity for high integrity procss-to-process
isolation.  At that point operating systems begin to differ dramatically
in their ability to resist viruses.

They differ in terms of the amount of generality, flexibility, and
transitivity that they reserve to the user.  The more that they are
prepared to reserve to themselves, the more resistant they are.

Applications also vary dramatically.  Those that do not permit user
programming (yes Virginia, there are such applications) are
significantly less vulnerable than those that do.  Those that maintain
strong segregation between data and procedure are also less vulnerable.

William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
=========================================================================
Date:         Mon, 12 Sep 88 22:55:54 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      Re: Different Operating Systems
In-Reply-To:  <QUCDN.X400GATE:LVVG8F1Y*>

>
>David Slonosky asks "Are all operating systems equally vulnerable?"  Of
>the examples that he calls out the answer is essentially yes.  This is
>because they are all designed for personal computing and for single
>state processors.  However, we when you get into multi-state systems you
>begin to enjoy the opportunity for high integrity procss-to-process
>isolation.  At that point operating systems begin to differ dramatically
>in their ability to resist viruses.
>
>William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
>2000 National City Center Cleveland, Ohio 44114
>21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

Ok, so what are examples of multi-state systems? Anything below the
minicomputer/mainframe range?

                                       __________________________________
                                      |                                  |
David Slonosky/QueensU/CA,"",CA       |         Know thyself?            |
<SLONOSKY@QUCDN>                      |  If I knew myself, I'd run away. |
                                      |__________________________________|
=========================================================================
Date:         Tue, 13 Sep 88 02:49:43 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         me! Jefferson Ogata <OGATA@UMDD>
Subject:      data/code

People seem to talk quite glibly of the distinction between data and
procedure around here.  What's your dividing line?  One man's data is
another man's procedure...

- Jeff Ogata
=========================================================================
Date:         Tue, 13 Sep 88 04:38:10 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      Virus research paper by ex-Lehigh student
In-Reply-To:  <QUCDN.X400GATE:LVWUUsDw*>

This is an impressive summary of what has been discussed
on this list for the past six months (or so). Is this material
copyrighted, or are we free to distribute it?

                                       __________________________________
                                      |                                  |
David Slonosky/QueensU/CA,"",CA       |         Know thyself?            |
<SLONOSKY@QUCDN>                      |  If I knew myself, I'd run away. |
                                      |__________________________________|
=========================================================================
Date:         Tue, 13 Sep 88 07:51:09 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ken van Wyk <[e-mail]>
Subject:      Re: Virus research paper by ex-Lehigh student
In-Reply-To:  Your message of Tue, 13 Sep 88 04:38:10 EDT

> This is an impressive summary of what has been discussed
> on this list for the past six months (or so). Is this material
> copyrighted, or are we free to distribute it?

It's not surprising that Mr. Kiels paper reflects a lot of what has
been discussed here; he used VIRUS-L as a major source of information
for his paper.

Steve gave me permission to "do with it as I please", so I sent it out
to VIRUS-L.  He did want me to keep any responses that I receive so
that he can read the reactions of our readers.  Anyway, I don't see
any problem with distributing it in its original form, as long as you
give credit to Steve and his co-author.

Ken



Kenneth R. van Wyk                   Calvin: Ever consider the end of the
User Services Senior Consultant        world as we know it?
Lehigh University Computing Center   Hobbes: You mean nuclear war?
Internet: <[e-mail]> Calvin: I think Mom was referring to if I
BITNET:   <LUKEN@LEHIIBM1>             let the air out of the car tires again.
=========================================================================
Date:         Mon, 12 Sep 88 21:34:20 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         ENGNBSC@BUACCA
Subject:      Re: crc polynomials
In-Reply-To:  Message of Mon, 12 Sep 88 21:21:11 EDT


Without annotated source, I would be reluctant to completely
trust any program...   And it's a little tough getting annotated
source for some strange reason :-)

Bruce Howells
=========================================================================
Date:         Tue, 13 Sep 88 09:51:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         EAE114@URIMVS
Subject:      Dual CRCs

<Jeff Ogata>
< It IS possible for two different programs to have the same CRC for
< two different polynmials.

True, for any reasonable polynomials, but it gets harder very
quickly as you add more polynomials.  Esp. to do it on purpose.

Has anybody seen or heard of any virus designed to pass a CRC
check? Or is this more work than the casual psychopath
is willing to incur?

                     EAE114@URIMVS (ERISTIC)
=========================================================================
Date:         Mon, 12 Sep 88 23:04:02 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Steve <XRAYSROK@SBCCVM>
Subject:      Re:  Re:  CRC vs. encryption schemes


   Of course it's possible to have two different programs with two
different polynomials and the same CRC.  In fact, two different programs
can have the same CRC using the same polynomial (which is a weakness of
CRC schemes).  This should be immediately intuitively obvious just from
realizing that the number of possible (distinct) programs is far greater
than the number of available CRCs (but each program will have a CRC
assigned to it anyway), so the mapping of programs into CRCs cannot be
1 to 1.

-------------------------- ----------------------------------------------
Steven C. Woronick        | Disclaimer: These opinions are entirely my    |
Physics Dept.             | own.  No responsibility or liability is       |
SUNY @ Stony Brook        | assumed regarding the use or misuse or        |
Stony Brook, NY  11794    | the reliability of the information preceeding.|
                          | Just kidding...
-------------------------- -----------------------------------------------
=========================================================================
Date:         Tue, 13 Sep 88 09:21:01 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Re: Infecting "Good" Viruses
In-Reply-To:  Message from "Bernie" of Sep 12, 88 at 8:30 am

>
>I'm thinking more of viri which hide themselves on unused sectors.
>Mind, running a utility that erases all unused sectors and checks all
>files against the vtoc would be just as effective?
>
>
>

Not unless you have a map of all bad sectors to check against.  The
virus could just as well hide in sectors that it had marked as bad in
the FAT.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
=========================================================================
Date:         Tue, 13 Sep 88 10:56:52 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         ENGNBSC@BUACCA
Subject:      Re: Dual CRCs
In-Reply-To:  Message of Tue, 13 Sep 88 09:51:00 EDT

"Casual psychopath" - that's a contradiction in terms...
Also a dangerous assumption, I am sure there is at least one
"professional" psychopath out there...

=========================================================================
Date:         Tue, 13 Sep 88 11:12:36 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Re: Virus research paper by ex-Lehigh student
In-Reply-To:  Message from "Ken van Wyk" of Sep 13, 88 at 7:51 am

>> This is an impressive summary of what has been discussed
>> on this list for the past six months (or so). Is this material
>> copyrighted, or are we free to distribute it?
>
>It's not surprising that Mr. Kiels paper reflects a lot of what has
>been discussed here; he used VIRUS-L as a major source of information
>for his paper.
>
>Steve gave me permission to "do with it as I please", so I sent it out
>to VIRUS-L.  He did want me to keep any responses that I receive so
>that he can read the reactions of our readers.  Anyway, I don't see
>any problem with distributing it in its original form, as long as you
>give credit to Steve and his co-author.
>
>Ken
>

It is an excellent piece of work and I will be using it (credited) in
a paper I am giving this week.  Many thanks.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
=========================================================================
Date:         Tue, 13 Sep 88 12:29:20 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Bob Babcock <PEPRBV@CFAAMP>
Subject:      Re: Infecting "Good" Viruses
In-Reply-To:  [e-mail] message of Tue, 13 Sep 88 09:21:01 CDT

>>I'm thinking more of viri which hide themselves on unused sectors.
>>Mind, running a utility that erases all unused sectors and checks all
>>files against the vtoc would be just as effective?

>Not unless you have a map of all bad sectors to check against.  The
>virus could just as well hide in sectors that it had marked as bad in
>the FAT.

On a standard  360K floppy disk, a virus could make space to hide
most  of its code by formating  tracks  with  10 rather  than the
usual  9 sectors.   I know that this  works  because  my odd-ball
MS-DOS system supports  10 sector per track disk formats.   There
are programs which can look for non-standard  sector numbers, but
unless  you know the sector number,  you have to try every one up
to 255, and that is very time consuming.

You can get some protection  by not accepting  any disks with bad
sectors.  This is perhaps impractical  to require for hard disks,
but floppy  disks  are so cheap that you can just throw  away any
that  aren't  perfect.   This  might  even  be  a good  idea  for
protection  against  data loss due to marginal  media,  which  is
probably  more  likely  than  a  virus  infection.    (My  floppy
formating  program  does not have the capability  of marking  bad
sectors,  so it rejects  imperfect  disks.   Even buying  generic
disks, I only reject 1-2%.)

=========================================================================
Date:         Tue, 13 Sep 88 14:18:57 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Re: Infecting "Good" Viruses
In-Reply-To:  Message from "Bob Babcock" of Sep 13, 88 at 12:29 (noon)

> ...
>On a standard  360K floppy disk, a virus could make space to hide
>most  of its code by formating  tracks  with  10 rather  than the
>usual  9 sectors.   I know that this  works  because  my odd-ball
>MS-DOS system supports  10 sector per track disk formats.   There
>are programs which can look for non-standard  sector numbers, but
>unless  you know the sector number,  you have to try every one up
>to 255, and that is very time consuming.
>
>You can get some protection  by not accepting  any disks with bad
>sectors.

I what you say above is true, then no protection is good enough, since
the drive would show no bad sectors and still have 10% overspace for
use by the bad guys.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
=========================================================================
Date:         Tue, 13 Sep 88 17:18:40 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         brian bulkowski <GE710012@BROWNVM>
Subject:      CRCs

First, having two CRCs instead of one doesn't help all that much.
Remember that CRC's are polynomials, thus if you pick to prime CRCs
there is a single CRC that is the same, just not prime.

Second, if you publish the algorythm and the CRC it wouldn't be hard
to have a virus that has the same CRC and attacks only that one program.
(The algorythm I would use would be: if in program X, infect anything
 you can find. If you are in any other program, look for X, if you can
 find an uninfected one, infect it and disinfect yourself)
I don't find this hard at all. BUT, if you also publish the LENGTH of
the code, it would be MUCH MUCH harder, assuming there is no easy to
find empty space in the code. You would have to pervert existing code
along the lines of the CRC but retain functionality of the program.

What I would do to go around that is to take a relativly unused portion
of the program and overlay it. This, however, is user noticable (although
they may quickly suspect a virus). Using the CRC means that the virus would
probably have to be longer to make the CRC come out right, and I think
CRC algorythms should exploit this to be hard on virus writers. Like doing
the CRC on only the first bit of a long word, meaning that to get the CRC
right many long words *may* be needed.

Does anyone know enough math on this list to know how to calculate how long
the "fudge factor" - extra bytes to make the CRC come out right - would have
to be for a given CRC polynomial? That's the question.

Yours Virtually,
Brian B.
=========================================================================
Date:         Wed, 14 Sep 88 09:24:29 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject:      another amusing re-print from RISKS on virus existance



Here's a followup on a message which I posted a couple days ago; it, too,
is a re-print from the RISKS forum.

     Ken



Date: 12 Sep 88 22:35:54 GMT
From: [e-mail] (David Dyer-Bennet)
Subject: ``MS-DOS "virus" programs do not exist.'' (Re: RISKS-7.49)

In RISKS-7.49, Mark Moore writes about a public-domain software catalog
containing an article claiming that MS-DOS "virus" programs do not exist.  I
view this with a certain glee, because for several years I've been
attempting to follow up each story about viruses I hear; so far, the story
has either faded into the distance, or I have been told that they have the
virus isolated, but won't show it to me.  While I accept that people running
academic computer centers, in particular, have some justification for taking
a paranoid attitude (though I wasn't approaching them from within as a
student), I've been telling people for some time that by covering up viruses
the way they do, they are going to lead people to believe it's all a myth,
which in the long run is bad.  So let me just say, "I told you so." to those
who've been concealing the evidence.
                                         -- David Dyer-Bennet, Terrabit Software

    ...!{rutgers!dayton | amdahl!ems | uunet!rosevax}!umn-cs!ns!ddb
    [e-mail], ...{amdahl,hpda}!bungia!viper!ddb
    Fidonet 1:282/341.0, [phone] hst/2400/1200/300

Kenneth R. van Wyk                   Calvin: Ever consider the end of the
User Services Senior Consultant        world as we know it?
Lehigh University Computing Center   Hobbes: You mean nuclear war?
Internet: <[e-mail]> Calvin: I think Mom was referring to if I
BITNET:   <LUKEN@LEHIIBM1>             let the air out of the car tires again.
=========================================================================
Date:         Wed, 14 Sep 88 09:46:13 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David M. Chess" <CHESS@YKTVMV>
Subject:      CRCs

I *think* that, since a CRC is linear, you only need to be able
to twiddle something like 2n bits to fox an n-bit CRC, if you
know what the polynomial in use is.  Figuring out exactly what
the proper twiddling is is the hard part.  And foxing two n-bit
CRCs requires just twice as many bits, since using two n-bit CRCs
is Just Like using one 2n-bit CRC (for most intents and purposes).
Real mathematicians can correct me if I'm wrong (in either direction)!

DC
=========================================================================
Date:         Wed, 14 Sep 88 10:20:35 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Re: CRCs
In-Reply-To:  Message from "David M. Chess" of Sep 14, 88 at 9:46 am

>
>I *think* that, since a CRC is linear, you only need to be able
>to twiddle something like 2n bits to fox an n-bit CRC, if you
>know what the polynomial in use is.  Figuring out exactly what
>the proper twiddling is is the hard part.  And foxing two n-bit
>CRCs requires just twice as many bits, since using two n-bit CRCs
>is Just Like using one 2n-bit CRC (for most intents and purposes).
>Real mathematicians can correct me if I'm wrong (in either direction)!
>
>DC
>
I agree with David C.  It might take an extra byte or two to make it
work, but the agreement with n CRCs can be done fairly economically.

What if the distributor were to distribute the software through one
channel, and then through another channel, at a later date, distribute
the CRC equation or equations used.  Might that help?

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
=========================================================================
Date:         Wed, 14 Sep 88 09:59:52 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe McMahon <XRJDM@SCFVM>
Subject:      (Mac) HyperCard Virus Warning!

All HyperCard user, beware! A misguided (though well-meaning, I'm sure)
individual on Delphi has *** PUBLISHED THE SOURCE *** for the "Dukakis"
HyperCard virus! Not only that, but it was distributed to in the Mac
Digest?!?!?

Prepare for an onslaught of HyperTalk viruses, folks. It's just too darn
simple and (worse yet) well commented. I will be publishing the source for
a "set" handler you can install in your Home stack that will help trap
this particular virus.

How to make sure that you don't get infected by a stack?

 - Refuse to use any stack which does not allow you to change the userLevel
   or is password-protected.

- Read the handlers in any new stack, watching out for "set the script of..."

I will see if I can cook up a stack which will analyze a new stack and show you
any scripts which attempt to modify other scripts. It will most likely get a
number of false alarms, but it will be better than nothing.

I'm not going to mention a couple of ways I can think of to get round this...

--- Joe  M.
=========================================================================
Date:         Wed, 14 Sep 88 13:07:02 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         ENGNBSC@BUACCA
Subject:      Re: CRCs
In-Reply-To:  Message of Wed, 14 Sep 88 10:20:35 CDT

I don't think that published CRC will be the answer - I've seen
software appear on bulletin boards within a few days of it's release;
as soon as a new 'clean' CRC is published, anyone who really
wanted to infect it could have a new mutation set up.

Bruce Howells, [e-mail], [e-mail]
=========================================================================
Date:         Wed, 14 Sep 88 14:46:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Jerry Leichter ([e-mail])" <LEICHTER@YALEVMS>
Subject:      RE: Re: CRCs

The mathematics of CRC's is very simple.  The basic idea can be seen more
easily by using a much simpler algorithm:  Consider an input file as a very
long binary number B.  Choose a some fixed number N, and compute the remainder
of B divided by N.  The result is between 0 and N-1, and is your checksum.

Suppose I have a modified file which, viewed as a long binary number, has
value B'.  If remdr(B',N) = remdr(B,N), my modified program will have the same
checksum as the original, and will fool you.  I can ensure that by computing
B'' = B' - remdr(B',N) + remdr(B,N); then remdr(B'',N) is "correct".  Of
course, in the process I may have screwed up the program:  When viewed as a
set of bits, B'' may not work correctly.  However, in general B' and B''
differ only in the last couple of bits, so I may get away with this.  In
addition, B'' + k*N has the same remainder mod N as B'', for any integer k,
so I can try to fiddle things around to find a version that DOES work.

Now, no one actually uses remainders of programs viewed as large integers
for checksums because they are very expensive to compute.  CRC instead uses
a related idea:  Instead of viewing the bits in the program as specifying a
binary number, think of them as giving the coefficients of a huge polynomial
P:  The first bit is the coefficient constant term, the second the x term, the
third the x^2 term, and so on.  Instead of a number N, choose a polynomial Q.
As before, compute the remainer of P divided by Q.  The result is the check-
sum.  The checksum is a polynomial of degree at most deg(Q)-1.

Now, you COULD view the polynomial as having real numbers as coefficients -
where the input coefficients happen all to be 0 or 1 - but then it's just as
hard to compute the result as to do the integer long division, and besides you
don't get some advantages I'll mention in a moment.  Instead, you view the
coefficients of P as being in the integers mod 2, which is a perfectly good
field to do arithmetic in.  You must then chose Q to be a polynomial over the
same field - so all its coefficients are 0 or 1 - and the same with the
remainder (so the remainder is just a bunch of bits, too).

Arithmetic for integers mod 2 is very simple:  Addition is the same as XOR,
and multiplication is the same as AND.  It turns out that you can implement
this very simply as a feedback shift register.  What this comes down to is
imagining your high-school long-division algorithm for polynomials, simplified
in two ways:  The arithmetic is XOR's and AND's, and the quotient doesn't
matter - all you need is the remainder.  The first of these allows for very
simple circuitry.  The second means you can toss away high-order terms as you
finish with them:  You only need to work on a segments as long as Q is.
Further, the process just proceeds right to left, never looking ahead or back;
so you can checksum a stream of bits "on the fly", as you send or receive
them.

These properties make CRC's very easy to compute.  In addition, they have a
nice property which is easy to see from just thinking about the way polynomi-
als work:  If you flip some bits of P, but no two bits you flip are further
apart than the degree of Q (plus 1), then the remainder ALWAYS changes.  What
this means is that CRC's are very good at detecting "burst" errors:  Groups of
clobbered bits close to each other.  The errors seen on communications lines
are usually the results of short "noise events", and are thus burst errors; so
CRC's are an excellent choice for detecting them.  Also, errors on disks are
usually the result of physical damage to a tiny piece of the disk surface, so
they, too, are burst errors.  Same for tapes.  That's why CRC's are so widely
used.

The burst error detection capability is quite irrelevent for many applica-
tions.  For example, I've seen people use CRC as hash functions in hash
tables.  This is a waste of effort; there are much simpler, easier to compute
functions that will work just as well in this application.

Similarly, CRC's as such have little to recommend them as signature functions.
If you think about how they work, you'll see that fooling a known CRC is very
easy - even easier than in the case of the "remainder mod N" example, since
you can produce any CRC you want by modifying just the trailing deg(Q)+1 bits
of the input.  What Rabin pointed out, however, is that if you DON'T know the
polynomial, then your chance of making just the right modification is essen-
tially the same as that of guessing the polynomial, which can be made small
by chosing the polynomial from a suitably large set of candidates.

                                                        -- Jerry

=========================================================================
Date:         Wed, 14 Sep 88 13:52:20 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Kevin Trojanowski <[e-mail]>
Subject:      Virus in bad sectors


Something I thought of on the way to work today, concerning the idea of a
virus hiding in sectors marked as 'bad' in the FAT (or VTOC, or whatever).

Would it not be possible to write a device driver of sorts which checks all
sector reads against sectors marked as 'bad' in the FAT?  Then, if the sector
is indeed a 'bad' sector, return an error without allowing the sector to be read
at all.

One hole I can think of in this is if the author of the virus circumvents it
by doing direct reads with the hardware, avoiding DOS altogethor.  But that
seems a little more in depth than the average (but not all) virus author would
be willing to go.

-Kevin Trojanowski
 [e-mail]
 [e-mail] (if Internet access isn't an option)
=========================================================================
Date:         Wed, 14 Sep 88 14:02:08 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         me! Jefferson Ogata <OGATA@UMDD>
Subject:      crc polynomial bit twiddling

It all depends on the nature of the polynomial involved.  Consider the
scheme: s(i+1) = s(i) + (x[i] ** 3).  That is, the CRC is the sum of
all cubes of bytes in the file (lower 16 bits).  In most cases, it'll
take a lot more than 32 bits of twiddle factor to hit the same CRC.
Approach the problem in the following fashion: the original file has
some CRC m; the virus code has the CRC n.  In this CRC scheme, the CRC
of the combined file, i.e. after infection, is (m + n) mod (2 ** 16).
There are two cases: one where m + n >= 2 ** 16, and one where m + n <
2 ** 16.  Consider the latter case.  It is desired that (m + n) = m.
For this to happen, the virus must have a CRC of zero.  Consider the
other case.  Here we want (m + n) mod (2 ** 16) = m.  As in the first
case, the virus must have a CRC of zero.  So it is clear that the
virus must have a CRC of zero in order for it to escape CRC detection.
In order to get a zero CRC, we must pick bytes to add to the virus
that drive all the one-bits out of the CRC sum.  This can be done as
follows (C algorithm):
while (crc () mod (2 ** 3)) addbyte (1 ** 3);
while (crc () mod (4 ** 3)) addbyte (2 ** 3);
while (crc () mod (8 ** 3)) addbyte (4 ** 3);
etc.

Note that we cannot simply compute the sum of these bytes and add that,
because for any x and y, ((x + y) ** 3) <> (x ** 3) + (y ** 3).  If we
could find a sequence of bytes that has the same CRC as the sequence
generated by the above algorithm, we could use that sequence, but doing
so would be VERY difficult.

In order to arrive at a CRC of zero with only 32 bits of twiddling, the
CRC n of the untwiddled virus must be such that (n + a + b + c + d) mod
(2 ** 16) = 0, where a, b, c, and d are four perfect cubes of numbers
less that 256.  While any positive integer can be expressed as the sum
of four perfect squares, it will usually require more than four perfect
cubes.

Of course, this is a case of a cubic CRC polynomial.  Consider the linear
scheme: s(i+1) = s(i) + x[i].  This is merely the sum of all bytes in
the file (lower 16 bits).  Even this scheme requires that you add about
2 ** 8 bytes in some cases.  Suppose the untwiddled virus has a CRC of
one.  To hit zero, you must add bytes whose sum is 65535.  You'll need
257 bytes to do this.  (65535 / 255 = 257)

- Jeff Ogata
=========================================================================
Date:         Wed, 14 Sep 88 15:25:11 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         ENGNBSC@BUACCA
Subject:      Re: (Mac) HyperCard Virus Warning!
In-Reply-To:  Message of Wed, 14 Sep 88 09:59:52 EDT

Well, I guess we finally have "proof" of the existence of a virus...

Bruce Howells, [e-mail] / [e-mail]
=========================================================================
Date:         Wed, 14 Sep 88 15:42:33 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         portal!cup.portal.com![e-mail]
Subject:      Student paper

     The paper has one flaw in it that I can see.  It claims that Trojan horses
carry viruses in terms that imply that that's *all* Trojans do.  This can
clearly not be the case, as I personally know of many Trojans that do not
carry self-replicating programs.  Additionally, the term Trojan Horse as it
is used in the computer world was coined long before the term virus.


Dan Hankins

"These opinions are mine, and mine alone.  They are not for sale.  They may,
 however, be rented or leased at reasonable rates."
=========================================================================
Date:         Wed, 14 Sep 88 16:52:35 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David M. Chess" <CHESS@YKTVMV>
Subject:      crc polynomial bit twiddling - reply to J. Ogata

By "CRC", I meant the usual thing that's called a "cyclic redundancy
check", described so well just now in Jerry Leichter's posting:
the remainder when you treat both the data and the polynomial
as polynomials over the field [0,1], and determine the remainder when
dividing the one by the other.  I don't think the examples that you
give are CRCs in that sense?  The examples you give are, I think,
nonlinear in places that a real CRC is linear, and therefore may be
harder to fox with control of a small number of bits.  I intended
my posting only to apply to real CRCs, not to signature algorithms in
general.

DC
=========================================================================
Date:         Wed, 14 Sep 88 17:36:55 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         me! Jefferson Ogata <OGATA@UMDD>
Subject:      crcs

It is true that the schemes I was discussing are not true CRCs.  They
would probably be termed 'checksums'.

- Jeff Ogata
=========================================================================
Date:         Wed, 14 Sep 88 18:04:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Jerry Leichter ([e-mail])" <LEICHTER@YALEVMS>
Subject:      RE: crc polynomial bit twiddling

Jefferson Ogata discusses checksums of the form s(i+1) = s(i) + p(b[i+1]),
where b[i] is the i'th byte of the text to be checksummed and p is a
polynomial (actually, he only suggest p(x) = x^k for some k).

a)  This is a checksum based on polynomials, but it is NOT what "CRC" refers
to.  "CRC" has an established meaning in the computer science/electrical
engineer- ing/coding theory fields.  It means a checksum computed as the
remainder mod a polynomial over Z mod 2.

b)  Ogata suggests that even in the simple case p(x) = x, with a 16-bit sum
of 8-bit unsigned bytes as the checksum, producing a particular checksum
might require adding 65535 bytes to the file (e.g., if the file had a checksum
of 1 and the checksum you needed to fake happened to be 0).

This is true but again illustrates the dangers of not understanding the model
you are working with.  If the goal is to prevent the wholesale replacement of
the original file by another distinct but pre-specified file, such a checksum
might be worthwhile.  However, your opponent normally CHANGES the original
file, he doesn't replace it.  If your opponent needs to change k bytes of your
file, he can always hide the changes by changing some other k bytes:  For each
byte he added d to, he subtracts d from some other byte in the file.  Note
that this doesn't change the length of the file at all.

The same basic attack works for any polynomial p with the given scheme.

By the way, any such scheme has a much more profound weakness:  It is not
sensitive to re-ordering of the bytes in the file.  I can probably find all
the bytes I need to construct my virus SOMEWHERE in your program.  I need only
move them to the place I want them.  (Of course, if it's a data file like a
checking account record you are talking about, changing $109 to $901 is also
rather effective. :-) )

Sure, I'll break something in your program using either of these techniques,
but by the time you happen to use what I broke it will probably be way too
late to help you.

Changing Ogata's algorithm to:

        s(i+1) = p(s(i)) + b[i]

eliminates the rearrangement hole, and generally makes the previous "modify
bytes in pairs" attack impossible, but it has other vulnerabilities.  (BTW,
with p(x) = kx for a suitable k, this is my favorite algorithm for generating
a hash code in hash table algorithms.  I ignore overflows and chose k so that
r(i+1) = kr(i) is a good linear congruential random number generator mod 2^n,
assuming the arithmetic uses n bits.  This also makes a fairly good checksum
for detecting transmission errors - not as good as CRC, but very, very easy to
compute quickly in a tiny piece of easily portable code.)

Remember, the security of a technique is not based on how well it resists the
attacks YOU thought of, it is based on how well it resists the attacks your
OPPONENT thinks of!
                                                        -- Jerry=========================================================================
Date:         Thu, 15 Sep 88 00:02:22 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         me! Jefferson Ogata <OGATA@UMDD>
Subject:      Re: crc twiddling

I apologize for my previous confusing remarks where I used CRC in
place of checksum.

The example I gave required adding 257 bytes, not 65535.

The reason I discussed only adding bytes to the original file, rather
than modifying bytes in the file, is that as far as I know, virus
attacks are not effective if they crash the program they infect,
which is likely to happen if they twiddle bits in the original
program.  Any virus attack that crashes your program will be obvious
and not very pervasive.  In addition, bank data files are well out
of the arena of likely virus infection.  As far as rearranging bytes
in the original program to make the virus, this also is likely to
crash the program.

- Jeff Ogata
=========================================================================
Date:         Thu, 15 Sep 88 10:35:38 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Neil Goldman <NG44SPEL@MIAMIU>
Subject:      Re: Dual CRCs
In-Reply-To:  Message of Tue, 13 Sep 88 09:51:00 EDT from <EAE114@URIMVS>

><Jeff Ogata>
>< It IS possible for two different programs to have the same CRC for
>< two different polynmials.
>
>True, for any reasonable polynomials, but it gets harder very
>quickly as you add more polynomials.  Esp. to do it on purpose.
>
>Has anybody seen or heard of any virus designed to pass a CRC
>check? Or is this more work than the casual psychopath
>is willing to incur?
>
>                     EAE114@URIMVS (ERISTIC)

Although I have not actually seen a virus which has been designed to pass a
CRC check, I am of the school of thought that no virus prevention/detection
method is foolproof.

If the virus author is able to determine the polynomial used to detect file
changes by the detection scheme of a particular detection product (such as
disassembling an old version of FluShot which may still be in use), the
virus author could calculate the number of NOP (no-operation) instructions
which would need to be included the the virus to ensure that the CRC would
pass ok.

Neil A. Goldman                        [e-mail]

Replies, Concerns, Disagreements, and Flames expected.
Mastercard, Visa, and American Express not accepted.
=========================================================================
Date:         Thu, 15 Sep 88 10:19:16 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Re: CRCs
In-Reply-To:  Message from "Jerry Leichter" of Sep 14, 88 at 2:46 pm

>
>The mathematics of CRC's is very simple.  The basic idea can be seen more
>easily by using a much simpler algorithm:  Consider an input file as a very
>long binary number B.  Choose a some fixed number N, and compute the remainder
>of B divided by N.  The result is between 0 and N-1, and is your checksum.
>
>[...]
>you can produce any CRC you want by modifying just the trailing deg(Q)+1 bits
>of the input.  What Rabin pointed out, however, is that if you DON'T know the
>polynomial, then your chance of making just the right modification is essen-
>tially the same as that of guessing the polynomial, which can be made small
>by chosing the polynomial from a suitably large set of candidates.
>
>                                                        -- Jerry
>
>
Thank you jerry, just right.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
=========================================================================
Date:         Thu, 15 Sep 88 10:23:57 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Re: Student paper
In-Reply-To:  Message from "[e-mail]" of Sep 14, 88 at 3:42 pm

>
>     The paper has one flaw in it that I can see.  It claims that Trojan horses
>carry viruses in terms that imply that that's *all* Trojans do.  This can
>clearly not be the case, as I personally know of many Trojans that do not
>carry self-replicating programs.  Additionally, the term Trojan Horse as it
>is used in the computer world was coined long before the term virus.
>

There are several errors in the paper of that kind.  This does not
diminish its value however in that is gives one excellent example of
the spread of a virus in a "protected" environment, and in that it
gives a good list of commercial virus products and their prices.

It is a very useful document.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
=========================================================================
Date:         Thu, 15 Sep 88 10:35:53 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Re: Dual CRCs
In-Reply-To:  Message from "Neil Goldman" of Sep 15, 88 at 10:35 am

>Although I have not actually seen a virus which has been designed to pass a
>CRC check, I am of the school of thought that no virus prevention/detection
>method is foolproof.
>
>If the virus author is able to determine the polynomial used to detect file
>changes by the detection scheme of a particular detection product (such as
>disassembling an old version of FluShot which may still be in use), the
>virus author could calculate the number of NOP (no-operation) instructions
>which would need to be included the the virus to ensure that the CRC would
>pass ok.
>
>Neil A. Goldman                        [e-mail]
>

It does not require a string of NOPs to do this, just a jump around
two bytes and the inclusion of the suitable number in those two bytes.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
=========================================================================
Date:         Thu, 15 Sep 88 11:54:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Jerry Leichter ([e-mail])" <LEICHTER@YALEVMS>
Subject:      RE: Re: crc twiddling

        The example I gave required adding 257 bytes, not 65535.

Yes; I came to the same realization shortly after posting my note.

        The reason I discussed only adding bytes to the original file, rather
        than modifying bytes in the file, is that as far as I know, virus
        attacks are not effective if they crash the program they infect, which
        is likely to happen if they twiddle bits in the original program.  Any
        virus attack that crashes your program will be obvious and not very
        pervasive.

A virus can be a rather small program - a couple of hundred bytes is suffici-
ent.  Do you really believe I can't find 500 bytes to change in a 300K program
that will not result in a crash until you've run the program for weeks?  The
usual rule is that 10% of the code accounts for 90% of the cycles.  This
doesn't, of course, mean that the other 90% of the code is never executed, but
in practice any large program will contain TONS of code that, for all
practical purposes, is never needed.

Large operating systems, BTW, often contain more code to deal with error
recovery of various sorts than with normal operation.  Years might go by
before you noticed that that code wasn't working as specified.

Finally, any large program is certain to have code in it that can be made
smaller, often substantially smaller, especially if you are willing to make it
a bit slower and less accurate - properties you'd hardly ever notice in
typical operation.  Just how much it is possible to crunch code would probably
astound anyone who never had to work on the systems of 15 and 20 years ago,
when 128K bytes of main memory was almost incomprehensibly huge.  These days,
few people have to work under memory constraints - it's hard and gains you
nothing on systems they use.  But people skilled in this art do exist -
embedded systems of various sorts are still built with small (cheap) memories,
for example - and any serious virus writer could pick up the skills if he
so chose.

                    In addition, bank data files are well out of the arena of
        likely virus infection.

Again, be careful that you don't limit the problem you are willing to examine
so much that you miss things.  A Trojan horse program that scrambled some of
your data files by exchanging bytes here and there could do more damage to you
than many viruses.  If you had a checksum program, you might consider using it
to checksum your data files, just to protect against this kind of thing.  It
had better be harder to fool than the checksums you've proposed, or you'll
likely find yourself in worse shape for having trusted in it than if you had
never started using it at all!

                                 As far as rearranging bytes in the original
        program to make the virus, this also is likely to crash the program.

See above.

Again, remember that "I can't think of any way to do X" is not a reasonable
measure of how hard X is, unless you are VERY familiar with problems like X -
and even then, it's suspect.
                                                        -- Jerry
=========================================================================
Date:         Thu, 15 Sep 88 10:29:56 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Popular Level Paper

Not to be outdone by a couple of mere students, I am submitting my
paper that was first entered here in rough form.  It was published
this week in the UWM campus computing newsletter and is at a lower
level than the Keil and Lee paper that I read here this week.  It
serves a different audience.  Thanks to those of you who made
suggestions, I took some of them.





                         Potential Virus Attack
                                   by
                              L. P. Levine

     There  has been talk recently about the presence of  virus  programs
running on office computers.  There now are a significant number of  such
machines on this campus.  If a virus does infect a significant number  of
machines  here it is possible that many office IBM compatible (or  Macin-
tosh)  machines  will fail or lose files on the same day.  It will  be  a
very  unpleasant time and our  professional staff will be overwhelmed  by
requests  for  help and will take some time (weeks) to get  the  recovery
process  under  way.   Most of us are unaware of how  dependent  we  have
become on these desktop machines and how much we will be affected by  the
loss of data that may ensue.

     Perhaps  we should define some terms here.  There are  two  computer
program elements that need definition.

     First  is  a Trojan Horse program.  This sort of program,  like  its
historical  namesake, has two functions.  On the "outside" it does  some-
thing to encourage the user to run it.  Typically, Trojan Horse  programs
may be games, small support programs, such as directory listers, or even,
in  one  case already on record, commercial software  packages.   On  the
"inside"  however, the program does something unfriendly to the  computer
on  which it runs.  Some Trojan Horse programs delete files,  some  reset
clocks,  some mark disk areas as unusable and some change  the  operating
system  of the computer.  The most destructive of them cause  other  pro-
grams  to  change their nature, usually by adding instructions  to  those
programs  that  make  them Trojan Horse programs as  well.   These  added
instructions are often called computer viruses.

     A computer virus is a portion of a program that does not run  alone,
but  requires another program to support it.  In this sense it is like  a
biological  virus,  requiring a cell for a host in order to allow  it  to
work.   Since it does not run alone, it does not appear in any  directory
and  is  never directly executed.  It moves from program  to  program  by
making  each  program to which it is attached (infected so  to  speak)  a
Trojan  Horse  program for further software infection.  A  virus  may  be
programmed to appear to do nothing for a long time (remain dormant),  and
then, when some trigger event occurs, do whatever it is programmed to do.
The  movement of a virus program element from machine to  machine  occurs
when a Trojan Horse program is run on that machine.

     If  a  virus program element infects our office machines,  then  not
only  will  the company's office machines be affected, but the  home  ma-
chines  that many staff members now have will also have their  files  af-
fected by the very same virus, and at the same time.  If you are  prepar-
ing a paper for publication, writing or working on an exam, or  preparing
some important correspondence, you may well find that your machine  read-
able copies of that material will become unusable both at home and at the
office.

     This  paper  discusses some evasive action that you can  do  now  to
prepare  for  the  return of your machine to working order.   What  I  am
recommending  in  this paper is no more than good housekeeping and  is  a
practice that each of us should do anyhow, with or without the threat  of
some mysterious computer virus.

     What I will discuss for the next few paragraphs applies to users who
have  machines with either a floppy disk drive and a hard disk  drive  or
have two floppy disk drives on their computers.

     Step one:  Locate the original source disks for the operating system
you  are  now using on your computer.  This may no longer be  the  system
delivered  with your machine, you may well have had an upgrade.   DO  NOT
PUT  THESE DISKS INTO YOUR FLOPPY DRIVE YET.  Secure a few  dozen  write-
lock  tabs and put one on each of the delivery system disks.   (When  you
hold  a disk upright the right side of the disk has a 1/4"  square  notch
cut into the black paper jacket.  The write-lock tabs are black or alumi-
num  colored gummed paper tags about 3/4" X 1/2" that can be  stuck  over
the  edge  of the disk covering the front and back of this  notch.   When
that tab is in place it is not possible for the computer to write  infor-
mation onto a floppy disk.)

     Only after you have write-locked these disks should you put the disk
into the computer and compare the system on that disk with the system you
are using.  STOP AND READ THE NEXT SENTENCE! The simple act of  executing
the DIR command on an unlocked disk is enough to infect that disk with  a
virus  if your system is already infected and if the disk is  not  write-
locked.   I am not kidding.  There is a very small probability that  your
system  is already infected.  I recommend that you compare the  date  and
size  of the file COMMAND.COM on your original source disks and  on  your
working  disk or disks to see that they are the same.  For my system  the
results look like this:

                 ------------------------------------
                 C> dir a:\command.com

                 Volume in drive A is MS330PP01
                 Directory of  A:\

                 COMMAND  COM  25276 7-24-87  12:00a
                 1 File(s)      5120 bytes free

                 C> dir c:\command.com

                 Volume in drive C has no label
                 Directory of  C:\

                 COMMAND  COM  25276 7-24-87  12:00a
                 1 File(s)   7391232 bytes free
                 ------------------------------------

     Note that both copies of COMMAND.COM have the same date and time  of
creation (midnight on July 24th 1987) and both are the same size  (25,276
bytes).  The numbers for your machine may well differ from mine, but both
should be the same.  When those disks have been found, put them away in a
safe  place.  I recommend that they be put in a plastic storage  box  not
too near your computer.

     Step  two:  There are a small number of software packages  that  you
would  be  lost without.  In my case they include  WordStar,  dBase  III,
PKARC,  Kermit, and Directory Scanner.  These packages may well  be  pur-
chased  commercial  software  (WordStar, dBase  III),  shareware  (PKARC,
Directory Scanner), and freeware (Kermit).  In each case you should  have
an original source delivery disk for each of these packages.  Find  those
disks,  WRITE LOCK THEM, compare them with the copies you are now  using,
and  put  them in a safe place.  I recommend that they be  put  with  the
system  disks  discussed above.  (It is probably true that  the  creation
dates for the running copies of this sort of software will disagree  with
the creation dates for the delivery disks.  Installation of many of these
packages entails writing to the program.  That is not a problem.)

     Step  three:  Using the backup procedure of your choice,  perform  a
backup  of  the  system files on your computer.  If I was  using  a  dual
floppy  based system, I would simply make copies of my working  WordStar,
dBase III, PKARC, Kermit, and Directory Scanner disks.  If I was using  a
computer  with a floppy and a hard disk, I would use  backup-restore,  or
Fastback or some other package to back up the directories C:\WS,  C:\DB3,
C:\ARK, C:\KERMIT and C:\DS.  (Of course these directories have different
names  on your system.)  Write lock these backup disks.  Label them  with
today's  date.  Using your backup system compare the disks you have  just
backed up with the disks you are using to ensure that the backup  "took".
Put  the  backup disks in a safe place.  This will tie up  half  a  dozen
disks, but with disks now costing $0.35 each, you will probably find  the
$2 investment worth while.

     Step  four:   (This applies to those users who use hard disk based
computers.)   Prepare  a backup procedure that  will  permit  incremental
backups.   This will entail backing up the entire system once,  and  then
periodically  backing  up those files that have changed since  the   last
backup.

     Perform  such  incremental backups regularly.   After  several  such
incremental backups, the size of the backup set will become quite  large.
At  that  time, put the backup set away in a safe place  and  begin  with
another set of disks for a full system backup followed by several  incre-
ments.   When  the second set is full, put them away and  return  to  the
first  set.  This will afford a very secure set of backup files.  I  find
that 50 disks makes a good backup set.  Thus 100 disks would be used  for
the  double backup group.  I suspect that most users would need to  do  a
full  backup  about 4 to 8 times per year, requiring about  1/2  hour  of
manipulation  and  should do incremental backups about  twice  per  week,
requiring less than 5 minutes.

     (It is a very good idea to periodically test the backup system  with
a verification of what you have backed up.  Most file backup systems have
a Verify command to do this sort of test.)

     Step five:  Go back to your useful work.

     Recovery from the loss of one or a few files:

     Sooner  or  later  you will lose some files.   They  will  disappear
without apparent cause and you will blame the problem on a virus.  It  is
my  experience that in cases like this no virus is involved, the loss  of
files will be due to an operator error.  If you have been doing incremen-
tal  backups, then the simplest corrective action is to use  the  recover
feature  of the backup system that you are using and simply  restore  the
latest  copy  of  the lost file(s) to the hard disk.  If  you  have  been
conscientious in your backup practice, then the loss of work will  entail
just a few minutes or, at most, a few hours of rework.

     Recovery from the loss of the entire system:

     It  may happen that the entire hard disk seems to be lost.  This  is
serious  but, in most cases, is likely not the result of a  virus.   Most
failures  of the hard disk are due to hardware problems.  The best  solu-
tion is to repair the hardware if the technical people judge that that is
the  problem,  and then, after reformatting the hard  disk,  restore  the
system from your latest backup.  Almost without fail, this will result in
a complete return to a normal system.

     Really bad news, the restore does not work:

     This may well be the point of this memo.  If a virus has been plant-
ed  in  your system and has been set to trigger on some event,  then  the
only way to recover is to rebuild the system from scratch using the write
locked set of disks that I advised you to prepare above.  If these  disks
are not write locked, and if you mount them onto an infected system, then
the disks will be infected in turn and you may well be unable to  restore
from  a clean, uninfected source without returning to the  system  vendor
for a fresh copy of each of your executable programs.  On the  assumption
that you first build your system again from scratch, you may restore  all
of  the data files from your backup set.  (A data file is one  that  does
not  have the extension .com, .exe, or .sys.)  Any other file should  not
be able to carry a virus either between systems or over the backup  proc-
ess.

     Some facts:

     There is no reason ever to boot the system from a foreign disk whose
history you are not prepared to trust.  (For example, booting from a copy
protected  version of Lotus 1-2-3 is as secure as the  Lotus  corporation
can make it.)

     There  is  no reason why a disk used to transport data  between  ma-
chines  should  have a copy of the files  io.sys,  msdos.sys,  ibmio.sys,
ibmdos.sys or command.com on it.

     No  system to date has been infected by the transport to it of  data
files.  Only executable files (including device drivers and the operating
system itself) can be used as Trojan Horse programs.

                                                        Leonard P. Levine
                                                                Professor
                                           Department of Computer Science
                               College of Engineering and Applied Science
                                        University of Wisconsin-Milwaukee
                                               Milwaukee, Wisconsin 53201

                                                           [phone]
                                                           [phone]




=========================================================================
Date:         Thu, 15 Sep 88 15:30:04 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David M. Chess 862-2245" <CHESS@YKTVMV>
Subject:      Len Adleman?

I notice that Len Adleman is credited with coining the term
"virus" in "THE INFECTION OF PC COMPATIBLE COMPUTERS", and
in a VIRUS-L posting from Loren.   Does anyone have any more
details?   When and where was the term coined?  The earliest
use of the term that I have is in 1974, a paper by Gunn referenced
in Cohen's "Computer Viruses: Theory and Experiments".          DC
=========================================================================
Date:         Thu, 15 Sep 88 15:52:53 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David M. Chess" <CHESS@YKTVMV>
Subject:      THE INFECTION OF PC COMPATIBLE COMPUTERS

Nice paper!   A couple of nits/questions:

- Talking about COMMAND.COM, the paper says "a number of viruses
  have been discovered which infect this file."  I believe that
  that number is in fact "one" (the Lehigh virus).   Can anyone
  cite another COMMAND.COM-targetted virus that probably exists?
  (Vague rumors need not apply!)

- In a similar vein, I would advise being a little less confident
  when stating things like "four versions of the Israeli virus
  and seven versions of the Brain virus have been found."  It
  may be true in the most literal sense of "version" (anyone could
  create a "new version" of one of these by changing a text or
  no-op byte), but there doesn't seem to be any good evidence
  that it's *really* true, in the sense of there being that many
  versions that actually have some difference in their behavior.
  (Authors, especially in the popular press, always seem to be
  tempted to exaggerate, if only by implication, the number of
  different viruses they know of; makes them sound wiser...)

- The advice to write-protect COMMAND.COM should probably include
  a note that this will not in fact do any good against a virus
  whose author has thought of the possibility (and most probably
  will).   It's still not bad advice, but the user should be
  aware that it's not a Real Solution to anything.

I don't mean to imply in my first two points that I'm one of
these folks who doesn't believe viruses exist!   I know they
do.   I just don't think that there are as many different ones
loose in the world as some column-writers would like to imply.

DC
=========================================================================
Date:         Thu, 15 Sep 88 17:13:32 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe McMahon <XRJDM@SCFVM>
Subject:      "Dukakis" Vaccine (Mac)

Well, let's fight fire with fire. If somebody's going to publish a virus,
I'm going to publish the matching vaccine. To use this vaccine, cut on the
dotted lines, download it to your Mac, paste it into the scrapbook, and
then paste it into your Home stack in HyperCard. If that's beyond what you're
willing to try with HyperCard, get the newest version of my virus documentation
stack from LISTSERV at SCFVM -- it has a button that will do it for you.
(Note: that may not be available until tomorrow (9/16))

---------- CUT LOOSE ---------
-- Note: "Duk-akis" contains a dash here to prevent the vaccine from
-- detecting itself as a virus.

-- Script to detect the spread of the "Duk-akis" virus. It works by
-- trapping the "set" command. I haven't seen "Duk-akis", but I should
-- think that it works by setting the scripts of various objects to
-- whatever they were plus an "on openStack" handler. Well, by trapping
-- the "set" command, we can then find out if we are setting a script.
-- If we are, then we can sort of work like "Vaccine" does; i.e., we
-- prompt the user to see if he or she wants to allow the command to
-- continue. If it is stopped, then all scripts are halted.

-- Additionally, if the script contains the word "Duk-akis", then no
-- option is given Q the script is halted straight away.

-- THIS SCRIPT SHOULD BE INSTALLED IN THE "HOME" STACK,
-- IN THE STACK SCRIPT.

-- You can test this script by making a new stack, then keying the
-- following examples into the message box:
-- % "Set the script of this stack to empty"
-- % "Set the script of this stack to field 1"
-- % "set the script of this stack to Duk-akis" (don't type the dash)

-- Try it, I think you'll like it!

-- This script is free to everyone apart from the person who wrote the
-- "Duk-akis" virus. I just hope it affects every single stack he or
-- she has or gets in the future!

-- Regards to all from a truely devoted HyperCard fan,
-- Ian Summerfield
-- Technical Support Supervisor
-- Apple Computer UK Ltd.
-- CIS: 76657, 742
-- "Sysop" - AppleFone HyperCard BBS: Luton, England: 0582 584134

-- Modified slightly 8/22/88 by Joe McMahon to make sure that
--"set the scriptI" (vs. "set script") doesn't slip through.

-- Modified a bit more 8/29/88 by Joe McMahon to add Ian's fixes
-- to prevent the vaccine from detecting itself as a virus.

on set
  put "Duk"&"akis" into duk
  if the param of 1 is "script" or the param of 2 is "script" then
    get the params
    if last word of it is "to" then put it && "empty" into it
    put it into s
    if s contains duk then
      repeat 10
        play harpsichord tempo 300 "a b c b a b c b"
      end repeat
      answer duk&&"virus detected!" with "Halt scripts"
      answer "Okay, you're safe now! It didn't spread."
      exit to HyperCard
    end if
    play harpsichord tempo 200 "e c e c e c e"
    answer "Warning: Script change requested" with "Show me"
    repeat
      answer s with "Allow" or "Stop!" or "Show more"
      if it is "Allow" then pass set
      else
        if it is "Stop!" then
          answer "All scripts halted!"
          exit to HyperCard
        else
          put the userLevel into userSafe
          set userLevel to 5
          doMenu "New Field"
          get the number of card fields
          set rect of card field it to 0,19,512,342
          set style of card field it to scrolling
          put the params into card field it
          choose browse tool
          wait until not the mouseClick
          wait until the mouseClick
          choose field tool
          click at loc of card field it
          doMenu "Clear Field"
          choose browse tool
          set userLevel to userSafe
        end if
      end if
    end repeat
  else pass set
end set
--------- All right, you can stop here ---------

--- Joe M.
=========================================================================
Date:         Thu, 15 Sep 88 19:56:03 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         me! Jefferson Ogata <OGATA@UMDD>
Subject:      more twiddling...

>A virus can be a rather small program - a couple of hundred bytes is
>sufficient.  Do you really believe I can't find 500 bytes to change
>in a 300K program that will not result in a crash until you've run the
>program for weeks?
>...
>Finally, any large program is certain to have code in it that can be
>made smaller, often substantially smaller, especially if you are willing
>to make it a bit slower and less accurate - properties you'd hardly ever
>notice in typical operation.

Sure you can find 500 bytes you can change in many programs.  But I'll
bet you a Snickers bar you can't write a 500 byte program that can find
them.  I'll bet you a Mars bar that you can't write a 500 byte code
optimizer.

To be fair, though, one possibility that might not have occurred to you
is this: write a virus that compresses the original code before instal-
ling itself; then fills in bytes appropriately to match a checksum.  On
execution it decompresses the original code and runs it.  This allows
you to beat checksums, file size checks, and CRCs simultaneously.  And
the original program won't crash.  Such viruses have been discussed,
though not with the intention of beating virus detection methods.

>A Trojan horse program that scrambled some of your data files by
>exchanging bytes here and there could do more damage to you than many
>viruses.

Perhaps, but this is VIRUS-L.  I was discussing methods of protecting
against viruses.  In addition, I made no claims about the desirability
of the checksums I mentioned; I merely discussed some of the associated
math.  The fact that it's possible to circumvent the checksums is not
under investigation.  No method is perfectly foolproof.

- Jeff Ogata
=========================================================================
Date:         Fri, 16 Sep 88 08:37:49 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject:      Virus hits Japan (from RISKS forum)


     The following is a report on a so-called virus that has hit Japan.
     I thought that it was particularly interesting because it steals
     user passwords via a network.  The information is somewhat sketchy,
     but it doesn't appear (to me) to propogate, so doesn't seem to be
     a virus, but a clever password snatcher, even though the article
     refers to it as a virus (reprinted from RISKS forum).

     Ken



Date: Wed, 14 Sep 88 13:35:04+0900
From: Yoshio Oyanagi <[e-mail]>
Subject: The First "Virus" on Japanese PC

     PC-VAN, the biggest Japanese personal computer network operated by NEC,
was found to be contaminated by a kind of virus, several newspapers reported
today (September 14).  This is, as far as I know, the first virus reported on a
Japanese PC.  The viruses so far reported in Japan were all on American PC or
WS.  PC-VAN is a telephone based network between NEC PC9800 personal computers,
the best sold PC (> one million) in Japan.

     This virus does not destroy programs or data unlike those in US, but it
automatically posts the user's password on the BBS in crypto- graphic form.
The offender will later read the BBS and obtain the password.

     Several members of PC-VAN claim that they are charged for the access to
PC-VAN which they do not know.  This virus seems not to be contagious by its
own power.  The PC9800's OS was contaminated when the user carelessly run a
anonymously distributed program on the PC.

Kenneth R. van Wyk                   Calvin: Ever consider the end of the
User Services Senior Consultant        world as we know it?
Lehigh University Computing Center   Hobbes: You mean nuclear war?
Internet: <[e-mail]> Calvin: I think Mom was referring to if I
BITNET:   <LUKEN@LEHIIBM1>             let the air out of the car tires again.
=========================================================================
Date:         Fri, 16 Sep 88 08:41:50 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject:      a hole (and cure) in GNU EMACS, from RISKS


     The following (also from RISKS) is a report on a security hole in
     GNU EMACS, along with a cure.  Does anyone know of any viruses that
     have used this EMACS "feature"?  GNU EMACS users should (imho) read
     this carefully, and add the fix listed below in the .emacs file.

     Ken


Date: Thu, 15 Sep 88 08:32:45 PDT
From: the terminal of Geoff Goodfellow  <[e-mail]>
Subject:  GNU Emacs & Security (A.Gaynor via Eliot Lear)

Return-Path: <[e-mail]>
Date: Wed, 14 Sep 1988 11:48:10 PDT
From: Eliot Lear <[e-mail]>
To: [e-mail]
Usmail: 700 East El Camino Real, Mtn View, California 94040
Phone: [phone]
Subject: [[e-mail] (Silver) : GNU Emacs & Security ]

[The following was discovered by one of the Rutgers systems programmers.  It
is similar to the old "vi:" bug in that visiting a file may cause execution
of an arbitrary set of commands including shell escapes...  I am told that
this has not been brought up on hg before.-eliot]

From: [e-mail] (Silver)
Subject: GNU Emacs & Security

This message is being sent to everyone in group slide.  I've wandered across an
application of a feature of GNU Emacs that may allow sliders to fall victim to
trojan horses arbitrarily stuck in files.  The feature in question is the `file
variables' section of a file.  Upon reading the file, portions of text may be
evaluated, with perhaps profound results.  For example, using this feature I
was able to create a file that copied /bin/sh to my home directory, and chmod
it to run setuid root.  It wasn't hard at all.  With a little effort, I'm sure
I could have made its effects totally transparant.

So, protect yourself by inserting the following at the root level of your
.emacs:

  ;; Protect thine arse from the Trojan file-variables section.
  (setq inhibit-local-variables t)

The pertinent portion of this variable's documentation reads, "Non-nil means
query before obeying a file's local-variables list.".  So, from now on, it's
going to ask you if you want to process the variables if they are present.
Only answer `y' if you trust this file not to put you through a blender.  If
you answer `n', you can always look at the variables somewhere within the last
3000 characters of the end of the file, and, if they appear reasonable, say
`M-x normal-mode' to process them.

Regards, [Ag] [e-mail]

Kenneth R. van Wyk                   Calvin: Ever consider the end of the
User Services Senior Consultant        world as we know it?
Lehigh University Computing Center   Hobbes: You mean nuclear war?
Internet: <[e-mail]> Calvin: I think Mom was referring to if I
BITNET:   <LUKEN@LEHIIBM1>             let the air out of the car tires again.
=========================================================================
Date:         Fri, 16 Sep 88 06:27:42 PDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Robert Slade <USERCE57@UBCMTSG>
Subject:      Rearranging program guts

An object code optimizer would be a pretty sophisticated program to try and
imbed into a small virus.  Also, adding to one place and taking from another
or rearranging the bytes in order to imbed your code would require a program
with a lot of smarts regarding how often a piece of code is likely to be
executed, and *still* wouldn't fox the smarter CRC programs.  Still, it would
be a prime use for a targetted virus, and not all checking programs are all
that smart.
=========================================================================
Date:         Fri, 16 Sep 88 12:37:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Jerry Leichter ([e-mail])" <LEICHTER@YALEVMS>
Subject:      RE: Rearranging program guts

I was NOT proposing that a virus optimize a random program it found on your
disk in order to find place to insert itself.  Nor was I suggesting that it
search around in random programs for "safe" positions.  The PROGRAMMER of the
virus would find the safe position in some common file or files.  Only those
files would get infected.

A nasty virus of this sort would operate in two stages.  In stage 1, it would
spread through files it knew about, but do nothing harmful:  Infiltration.  In
stage 2, it would begin infecting other programs, which would then do damage,
perhaps after a further delay:  Sabotage.  The stage 1 infection would be very
difficult to detect - there would be no clue that anything untoward was happen-
ing at all.  Only explicit tests, like checksums on files, could detect the
infiltration - and it is exactly ways of bypassing those that we are discussing
here.

If stage 1 were to delay long enough - 6 months, a year - you would likely
find that you had no uninfected backups anywhere.

Since the connection between the infection of OTHER programs of stage 2 and
the hidden stage 1 virus would be tenuous, even figuring out that there WAS a
stage 1 virus around would take a while - and finding it might be hard.

A really nasty approach would be for stage 1 to be targeted at backup programs
(where it would stay latent forever) and file transfer programs (where it would
eventually infect files as it transfered them).  This would make it look as if
the stage 2 infection came from a recent up-load.

How likely are these scenarios?  Who knows.  The point is, if you are going to
rely on a virus detection mechanism, you had better have a LOT of confidence
that it is hard to defeat - or you open yourself up to big headaches later.

                                                        -- Jerry
=========================================================================
Date:         Wed, 21 Sep 88 08:31:04 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ken van Wyk <[e-mail]>
Subject:      Donald Gene Burleson found guilty

I just read an Associated Press (by Tim Lott) news article in an
Allentown PA newpaper which said that Donald Gene Burleson, a former
programmer, was found guilty of planting a computer virus.  The
article said that this was the first conviction in the country for
such a case.  Hopefully it will set a precedent.  The conviction
itself was for "harmful access to a computer, a third-degree felony
that carries up to 10 years in prison and up to $5,000 in fines."
According to the article, "A key to the case was the fact that State
District Judge John Bradshaw allowed the computer program that deleted
the files to be introduced as evidence".  Apparently, the virus, if
indeed it was a virus, was "activated like a time bomb, doing its
damage two days after (the defendant) was fired".

It is not clear, to me, that the program was actually a virus and not
a simple time bomb.  The article adds further confusion to the matter
by defining a virus as "...a computer, often hidden in apparently
normal computer software, that instructs the computer to change or
destroy information at a given time or after a certain sequence of
commands."  Nonetheless, Mr. Burleson was convicted.  His attorney
expects him to get "the minimum sentence of two years' probation".

It will be interesting to see if more such cases come to light as a
result of this one.

Ken



Kenneth R. van Wyk                   Calvin: Here, try this new cereal,
User Services Senior Consultant         Chocolate Frosted Sugar Bombs.
Lehigh University Computing Center   Hobbes: Gack!  Ptui!  :-(
Internet: <[e-mail]> Calvin: Yeah, they're a bit bland until
BITNET:   <LUKEN@LEHIIBM1>              you scoop some sugar on them.
=========================================================================
Date:         Wed, 21 Sep 88 08:52:20 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ken van Wyk <[e-mail]>
Subject:      info on court case


The conviction that I described earlier, by the way, was in Fort Worth,
Texas.  Sorry I neglected to mention that before...

Ken

=========================================================================
Date:         Wed, 21 Sep 88 09:42:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         NEWTON@NBSENH
Subject:      Viruses hit the big time...

For anyone who hasn't been by a newsstand yet, the current TIME magazine
cover is on computer viruses.  Haven't read it yet, but thought that this
was worth mentioning.

Barry
=========================================================================
Date:         Wed, 21 Sep 88 12:46:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         me! Jefferson Ogata <OGATA@UMDD>
Subject:      2 years probation

It's fascinating that there has actually been a conviction, but I must
say two years probation is not likely to serve as the least deterrant
to future virus attacks.  Probation is a breeze.

- Jeff Ogata
=========================================================================
Date:         Wed, 21 Sep 88 13:07:32 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Bruce Howells <ENGNBSC@BUACCA>
Subject:      2 years probation


Probation might be a breeze, but...
if you were an admissions officer, or interviewing someone, would you
accept/hire them into a cs position if they had been convicted of
attacking a system via virus?

Bruce Howells, [e-mail], [e-mail]
 - These opinions are my own; and in no way represent those
   of Boston University or any other organization.

(boring disclaimer, but it seemed important on that one.)
=========================================================================
Date:         Wed, 21 Sep 88 11:43:13 PST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         PJS%naif.JPL.NASA.GOV@HAMLET
Subject:      RE:       2 years probation

SIGNOFF VIRUS-L=========================================================================
Date:         Thu, 22 Sep 88 00:27:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Dimitri Vulis <DLV@CUNYVMS1>
Subject:      Viruses and media

In one of the first paragraphs, the TIME story describes the user struck
by a virus seeking through all 360 concentric circles of data on the disk
(very near quotation from memory). Apparently, the writer confused a kilobyte
(as in 360K) with a track (as in 96tpi).
Also today, NY times ran a story (discussed here previously) about a guy
convicted of planting a time bomb, except it called it a virus. This is
actually an AP story, so it's mpt surprising: AP style manual has a section
called 'computer terms' which defined 'disk operating system' as a collection
of disks and disk drives to read them. However, I'd expect that Time magazine
would let someone who knows the difference between a track and a Kbyte read the
story before printing it. I think it's highly irresponsible on the part of
the media to write about things they don't understand and to confuse the
public. Explaining the need for security to the users is hard enough
without it.

Dimitri Vulis, CUNY Math Department

P.S. My wife and I wrote a letter to AP about their Style manual listing
something like 50 inaccuracies in the computer section, mosr of them
quite funny; I can email a copy to interested parties, although it has
little direct bearing on the virus topic.
=========================================================================
Date:         Thu, 22 Sep 88 09:21:38 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ken van Wyk <[e-mail]>
Subject:      Time article bashes the media...

The cover story in the September 26, 1988, seems to be pretty interesting
reading for the most part.  Most of the facts are clearly stated, albeit in
flashy jargon.  At times, the jargon seems to border on sensationization, in
my opinion.  They do, however, go on to bash the media for its coverage of
viruses by saying, "...  On the other is the computer press, a collection of
highly competitive weekly tabloids that have seized on the story like pit
bulls, covering every outbreak with breathless copy and splashy headlines."
I thought this was amusing...

Ken



Kenneth R. van Wyk                   Calvin: Here, try this new cereal,
User Services Senior Consultant         Chocolate Frosted Sugar Bombs.
Lehigh University Computing Center   Hobbes: Gack!  Ptui!  :-(
Internet: <[e-mail]> Calvin: Yeah, they're a bit bland until
BITNET:   <LUKEN@LEHIIBM1>              you scoop some sugar on them.
=========================================================================
Date:         Fri, 23 Sep 88 16:49:26 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         SHERK@UMDD
Subject:      2 years probation
In-Reply-To:  Message received on Thu, 22 Sep 88  11:15:03 EDT

>It's fascinating that there has actually been a conviction, but I must
>say two years probation is not likely to serve as the least deterrant
>to future virus attacks.  Probation is a breeze.
>- Jeff Ogata
Is that from personal experience ??
=========================================================================
Date:         Sun, 25 Sep 88 22:58:09 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Bill Harris <WRH0@LEHIGH>
Subject:      Computer Virus and System Security Conference

This is to inform you that to the best of my knowledge, the "Computer
Virus and System Security Conference" is not sponsored by Lehigh
University.  In addition, I do not know if it is being held, October 21
- 23, as indicated in a message from Loren Keim in August.





   Telephone Number              Bill Harris, Director
   215-758-3830                  Computing Center
                                 EWFM 8B
                                 Lehigh University
                                 Bethlehem, PA.  18015

=========================================================================
Date:         Fri, 23 Sep 88 06:49:48 PDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Robert Slade <USERCE57@UBCMTSG>
Subject:      Media misunderstandings

Pursuant to the problems of Time and other media, I have seen a number of
articles in the same vein as the one recently distributed here which
     a) didn't know the difference between a virus, time bomb or trojan
     b) thought there was only one virus
These articles give the impression that there is *one* program doing the rounds
that will do everything nasty that's ever happened to computers.  (It must be
a super-virus.  It even infects mainframes and *all* makes of micros! :-)
=========================================================================
Date:         Fri, 23 Sep 88 11:27:00 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Bernie <BSWIESER@UNCAMULT>
Subject:      Back a bit...

In response to putting viri on sectors out of the normal range OR bad
sectors...

If the person in question has a knowledge of direct disk control, then
it wouldn't be hard to have his viri be in two steps.  The first visible
part would be a custom read routine to get the information on
non-standard formatted sectors.  The data on those would be the main
viral code.  This way, bad sectors would look bad to any program
checking if they are formatted normally.  However, any copy program
would skip this stuff (unless its a nibble copier) so the viri would
have to bhave write routines to format itself whenever a new disk is
detected...  On nice way to work would be to make the sync bytes into
viral code.  But all this is too much work for your fiddling hack, and
would have to be done by someone seriously determined to evade.  Anyone
who has written a good protection scheme for any system could hide such
a viri, because essentially the creator is "protecting" his virus.
(Simple example of such is EPYX's current protection scheme.  You can
copy it with anything but there are 8 tricky bytes on track 0 which the
program uses to decode the OS.  This is Apple//, but I've seen the same
on other machines.)
=========================================================================
Date:         Fri, 23 Sep 88 09:17:27 CST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Claudia Lynch <AS04@UNTVM1>
Subject:      Re: 2 years probation
In-Reply-To:  Message of Wed, 21 Sep 88 12:46:00 EDT from <OGATA@UMDD>

I agree, that 2 years probation doesn't seem like a big deal, but
just think of the PROFESSIONAL ramifications of the conviction. How
could he ever get another job in the computing industry? He would
have to change his entire identity. Not impossible, but not easy
either.


Claudia Lynch
Academic Computing Services
University of North Texas
Denton, Texas
=========================================================================
Date:         Fri, 23 Sep 88 08:22:13 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Re: Viruses and media
In-Reply-To:  Message from "Dimitri Vulis" of Sep 22, 88 at 12:27 (midnight)

>Dimitri Vulis, CUNY Math Department
>
>P.S. My wife and I wrote a letter to AP about their Style manual listing
>something like 50 inaccuracies in the computer section, mosr of them
>quite funny; I can email a copy to interested parties, although it has
>little direct bearing on the virus topic.
>

I have no way of reaching Dr. Vulis, but would like a copy sent to me.
Perhaps it is worth a posting.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
=========================================================================
Date:         Thu, 22 Sep 88 23:11:05 CST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         James Ford <JFORD1@UA1VM>
Subject:      HDSENTRY.ARC

Hello again.  A while (ok, a GREAT while) back I asked if anyone had ever
used HDSENTRY.COM.  I had been used it once, with some strange effects.

>First off, I'm using an IBM PS/2 M30 w/20M h-drive.  I backed up my harddisk
>and then ran the program.  I changed into a subdirectory and did a DEL *.*
>on it. The program gave the warning <<ALERT>> DESTRUCTIVE CALL BEING PREVENTED
>and didn't allow it.  Well, when I did a directory, it showed nothing.  BUT,
>after doing a warm boot, all files reappeared and ran fine.

After posting the above note, I asked if anyone would like to look at the ASM
file on it to (maybe) try and correct the above problem.  A couple of people
answered, but I couldn't locate the file.   NOW, I have the file.  Anyone
interested in doing a little debugging?  I would, but I don't know anything
about assembly.

                              James
=========================================================================
Date:         Fri, 23 Sep 88 15:57:15 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ken van Wyk <[e-mail]>
Subject:      "Virus Guide" from software vendor

In a recent (June or July?) issue of The Chronicle Of Higher
Education, there was a computer virus article in which an anti-virus
software vendor, RG Software Systems, offered to send anyone who
asked a free copy of a virus guide which they had written.  So, I
requested a copy of it on disk.  Here then, is the article (in the
interest of fairness, I did edit out some advertising information at
the end of the article):




                COMPUTER VIRUSES: A RATIONAL VIEW

                      by: Raymond M. Glath
                            President

                    RG Software Systems, Inc.
                       2300 Computer Ave.
                           Suite I-51
                     Willow Grove, PA 19090
                         [phone]


April 14, 1988


WHAT ARE COMPUTER VIRUSES?
(a.k.a. Trojan Horses, Worms, Time Bombs, Sabotage)

Any software that has been developed specifically for the purpose
of interfering with a computer's normal operations.


WHAT DO THEY DO?

There are two major categories of viruses.

Destructive viruses, that cause:

     Massive destruction...
          ie: Low level format  of disk(s),  whereby any programs
               and data on the disk are not recoverable.

     Partial destruction...
          ie: Erasure or modification of a portion of a disk.

     Selective destruction...
          ie: Erasure  or modification  of specific files or file
               groups.

     Random havoc... The most insidious form of all.
          ie: Randomly changing data on  disk  or  in  RAM during
               normal program applications, or changing keystroke
               values, or  data from  other input/output devices,
               with the result being an inordinate amount of time
               to discover and  repair  the  problem,  and damage
               that may never be known about.

Non-Destructive  viruses, intended  to cause  attention to the
     author or to harass the end user.

     a. Annoyances...
          ie:  Displaying  a  message,  changing  display colors,
               changing  keystroke  values  such as reversing the
               effect of the Shift and Unshift keys, etc.


WHAT IS THE IMPACT OF A VIRUS ATTACK BEYOND THE OBVIOUS?

Lost productivity time !!!

In addition to  the  time  and  skills  required  to re-construct
damaged data files, viruses can waste a lot of time in many other
ways.

With either type of virus, the person subjected to the  attack as
well as  many support  personnel from  the attacked site and from
various  suppliers,  will  sacrifice  many  hours   of  otherwise
productive time:

     Time to determine the cause of the attack.
     The removal of the virus code from the system.
     The recovery of lost data.
     The detective work required to locate the original source of
          the virus code.

     Then, there's the management time required to determine  how
          this will be prevented in the future.


WHO DEVELOPS VIRUSES?

This individual, regardless of his specific motivation, will most
probably want to see  some form  of publicity  resulting from his
handiwork.  Anywhere  from  a  "Gotcha"  message appearing on the
computer's screen after the  attack, to  major press  coverage of
that particular virus' spread and wake of damage.

Some of  the reasons for someone to spend their time developing a
virus program are:

     A practical joke.
     A personal vendetta against a company or  another person.
          ie: a disgruntled employee.
     The computer-literate political terrorist.
     Someone  trying  to  gain  publicity  for  some cause or
          product.
     The bored, un-noticed "genius," who wants attention.
     The mentally disturbed sociopath.


IS THE THREAT REAL?

Yes, however thus far the destructive ones have primarily been in
the Academic environment. Several attacks have been documented by
the press, and, from first hand experience, I  can attest  to the
fact that  those reported do exist. We have seen some of them and
successfully tested our Disk Watcher product against them.

Reputable individuals have reported additional viruses to us, but
these have  not reached the scale of distribution achieved by the
now  infamous  "Lehigh,"  "Brain,"   "Israeli,"  and  "MacIntosh"
viruses.

We do  expect the  situation to  worsen due to the attention it's
received. Taking simple lessons  from history,  a new phenomenon,
once  given  attention,  will  be  replicated  by individuals who
otherwise have no opportunity for personal attention.

Now that there are products for  defense from  viruses, the virus
writers have  been given  a challenge;  and for  those people who
have always wanted  to  anonymously  strike  out  at  someone but
didn't know  of a  method to  do so,  the coverage has provided a
"How To" guide.


HOW DOES A VIRUS GET INTO YOUR COMPUTER SYSTEM?

A virus may be entered into a system by an  unsuspecting user who
has been  duped by the virus creator (Covert entry), or it may be
entered directly by the creator. (Overt entry.)

     Examples of Covert  entry  of  a  virus  into  a computer
          system.

          A  "carrier" program  such as  a "pirate" copy of a
             commercial package that has been tampered with, is
             utilized  by  the  un-suspecting  user,  and  thus
             enters the virus code into the system.

             Other types  of  carriers  could  be  programs from
             Bulletin  Boards  that  have  been either tampered
             with  or  specifically  designed  as  viruses, but
             disguised as  useful programs. There has even been
             a  destructive  virus   disguised   as   a  "virus
             protection" program on a BBS.

          The  user  unknowingly acquires an "infected" disk
             and uses it to boot the system.

             The virus has been hidden in  the system  files and
             then hides  itself in  system RAM  or other system
             files in order to reproduce, and later, attack.


     Examples of Overt entry into a computer system.

          An  individual  bent  on  harassing  the  user  or
             sabotaging   the   computer  system,  modifies  an
             existing program  on  that  computer  or  copies a
             virus  program  onto  someone's  disk during their
             absence from their work station.


HOW DOES A VIRUS SPREAD?

A virus may reproduce itself by delaying its attack until  it has
made copies  of itself onto other disks (Active reproduction,) or
it may depend entirely on unsuspecting users to make copies of it
and pass  them around  (Passive reproduction).  It may also use a
combination of these methods.


WHAT TRIGGERS THE VIRUS ATTACK?

Attacks begin upon the occurrence of a certain event, such as:

     On a certain date.
     At a certain time of day.
     When a certain job is run.
     After "cloning" itself n times.
     When a certain combination of keystrokes occurs.
     When the computer is restarted.

One way or  another,  the  virus  code  must  put  itself  into a
position to  either start  itself when the computer is turned on,
or when a specific program is run.


HOW DOES ONE DISTINGUISH A VIRUS FROM A "BUG" IN  A PROGRAM  OR A
HARDWARE MALFUNCTION?

This can  be a tough one. With the publicity surrounding viruses,
many people are ready  to  believe  that  any  strange occurrence
while computing  may have  been caused  by a virus, when it could
simply be an operational error, hardware component failure,  or a
software "bug."

While  most  commercial  software  developers test their products
exhaustively,  there  is  always   the   possibility   that  some
combination of hardware; mix of installed TSR's; user actions; or
slight incompatibilities with "compatible" or "clone" machines or
components; can cause a problem to surface.

We need to remember some key points here:

1. Examine the probabilities of your having contacted a virus.

2. Don't  just assume  that you've  been attacked  by a virus and
     abandon  your  normal  troubleshooting  techniques  or those
     recommended by the product manufacturers.

3. When  in doubt  contact your  supplier or the manufacturer for
     tech support.

4. Having  an effective  "Virus Protection"  system installed may
     help you determine the cause of the problem.


HOW CAN YOU AVOID COMING IN CONTACT WITH VIRUSES?

1.  Know  and  be  comfortable  with  the source of your software
     acquisitions.

     If you use a BBS (Bulletin Board,) verify that the BBS is
        reputable  and  that  it has satisfactory procedures in
        place to check out its software  as well  as provisions
        to prevent that software from being modified.

     Do not use illegitimate copies of software.

     Be  sure that  the developer of the software you're using
        is a professional. Note that many  "Shareware" products
        are  professionally  produced.  You  needn't stop using
        them. Just be sure that you  have a  legitimate copy of
        the program if you choose to use these products.

     Don't  accept  free  software  that looks too good to be
        true.

2.  Install  a  professional  virus  protection  package  on your
     computer that will alert you to any strange goings on.

3.  Provide physical security for your computers.
     ie: Locked rooms; locks on the computers; etc.

4.  If you're unsure of a disk or a specific program, run it in an
     isolated environment  where it  will not  be able  to do any
     damage.

     ie: Run  the program on a "diskette only" computer, and keep
          a write-protect tab on your "System Disk."

         Run  the   program  with   "Virus  Protection"  software
          installed.

5.  Establish and maintain a sound Back-Up policy.

     DO  NOT   USE  ONLY  ONE  SET  OF  BACK-UP  DISKS  THAT  ARE
     CONTINUOUSLY WRITTEN OVER.

     Use at least three complete sets of back-up disks that are
      rotated in a regular cycle.


DO YOU  NEED SOME  FORM OF PROTECTION FROM VIRUSES?

It couldn't hurt !!!  You do lock the door to your home
  when you go out, right?

Plan in advance the methods you'll use to ward off virus attacks.
It's a  far more  effective use  of management  time to establish
preventative  measures  in  a  calm environment instead of making
panic decisions after a virus attack has occurred.


IS THERE ANY SOLUTION AVAILABLE THAT'S ABSOLUTELY FOOLPROOF?

No !!!

Any  security  system  can  be  broken  by  someone dedicated and
knowledgeable enough to put forth the effort to break the system.


WHAT LEVEL OF PROTECTION DO YOU NEED?

This of course depends on many factors, such as:

     1. The sensitivity of the data on your PC's.
     2. The number of personnel having access to your PC's.
     3. The security awareness of computing personnel.
     4. The skill levels of computing personnel.
     5. Attitudes, ethics, and morale of computing personnel.

A key point of consideration is the threshold  for the  amount of
security you can use versus its impact on normal productivity.

Human nature  must also  be considered. If you were to install 10
locks on your front door and it cost you 5 minutes each  time you
enter  your  home,  I'll  bet  that  the  first  time  that  it's
raining... and you have 3 bags of groceries... you'll go  back to
using the one lock you always used.


HOW CAN A SOFTWARE PRODUCT PROTECT AGAINST VIRUSES?

There are several approaches that have been developed.

One form  is an "inoculation" or "signature" process, whereby the
key files on a disk are marked in a special  way and periodically
checked to see if the files have been changed.  Depending on the
way in which this is implemented, this method can actually interfere
with programs that have built-in integrity checks.

Another method  is to  "Write Protect"  specific key areas of the
disk so that no software is permitted to change the data in those
places.

We  at  RG  Software  Systems,  Inc.  believe  that  preventative
measures are the most effective. The Disk Watcher system provides
multiple lines  of defense:  A "Batch" type program automatically
checks all active disk drives for the presence  of certain hidden
virus  characteristics  when  the  computer is started, and a TSR
(Terminate and Stay Resident) program monitors  ongoing disk
activity  throughout  all processing. The "Batch" program
can also be run on demand at any time to check the disk in a
specific drive.

The TSR program, in addition to its other "Disaster
Prevention" features, contains a series of proprietary algorithms
that detect the behavior characteristics of a myriad of virus
programs, and yet produce minimal  overhead in processing time
and "false alarm" reports. Disk  Watcher is uniquely able to tell
the difference between legitimate IO  activity and  the IO activity
of a virus program.

When an action occurs indicative of a virus attempting to reproduce itself;
alter  another program; set itself up  to be  automatically run  the next
time the system is started; or attempting to perform a massively damaging
act; Disk Watcher  will  automatically  "pop  up."  The user will then have
several options, one of which is to immediately stop the computer before any
damage can be done. Detection occurs BEFORE the action takes place.

Other options allow the user to tell Disk Watcher to continue the
application program  and remember  that this program is permitted
to perform the action that triggered the "pop up."

   Some very important features of Disk Watcher are:

   Whenever the user selects the "Stop the Computer" option, the
   Application screen image and the Disk Watcher screen image will be
   sent to the system printer before the machine is stopped, so that
   an effective analysis of the problem may be done.

   Disk Watcher performs an integrity check on itself whenever it runs.

The  "Destructive"   viruses   that   produce   "selective"  file
destruction or  "Random Havoc"  are the  most difficult to defend
against. The best measures are to prevent them  from getting into
the system in the first place.


WHICH VIRUS PROTECTION PACKAGE IS RIGHT FOR YOU?

Since the first reports of virus attacks appeared in the press, a
number of  "Virus Prevention"  products have  quickly appeared on
the market, produced by companies wishing to take  advantage of a
unique market  opportunity. This  is to  be expected. RG Software
Systems, Inc. is one of them with our Disk Watcher product.

It should be pointed out, however, that as of this  writing, only
a  little  over  2  months  has  transpired since the first major
stories appeared.

Those companies  that have  had to  build a  product from scratch
during  this  limited  amount  of  time  have  had  to design the
defensive  system,  write  the  program  code,  write  the user's
manual,  design  the  packaging,  "Alpha"  test, "Beta" test, and
bring their product through manufacturing to market. A monumental
task in a miraculously short period of time.

Companies that have had products on the market that include virus
protection, or  products  that  were  enhanced  to  include virus
protection, such  as Disk  Watcher, have had extra time and field
experience for the stabilization of their products.

As a  professional in  this industry,  I sincerely  hope that the
quickly developed products are stable in their released form.

The evaluation points listed below are usually applied as a
standard for all types of software products:


         *Price
         *Performance
         *Ease of Use
         *Ease of Learning
         *Ease of Installation
         *Documentation
         *Copy Protection
         *Support

A "Virus Protection" package, like a security system for your
home, requires a close scrutiny.  You want the system to do the
job unobtrusively, and yet be effective.

TWELVE SPECIAL CONSIDERATIONS FOR VIRUS PROTECTION PACKAGES:

1.  Amount  of  impact  the  package  may have on your computer's
     performance.

     If the package is  "RAM Resident,"  does it  noticeably slow
          down your machine's operations?
     If so,  with what type of operation?  Are program start-
          ups slowed? Are database operations slowed?


2. Level of dependency on operator intervention.

     Does the package require  the  operator  to  perform certain
          tasks  on  a  regular  basis  in  order  for  it  to be
          effective? (Such as only checking for  virus conditions
          on command.)
     Does  the  package  require  much  time  to install and keep
          operational?  ie:  Each  time   any  new   software  is
          installed on the system, must the protection package be
          used?

3. Impact on productivity... Annoyance level.

     Does the package periodically stop processing and/or require
          the  operator  to  take  some  action.  If so, does the
          package have any capability  to  learn  its environment
          and stop its interference?

4. False alarms.

     How  does  the  package  handle situations that appear to be
          viruses but are legitimate  actions made  by legitimate
          programs?
     Are there  situations where  legitimate jobs will have to be
          re-run  or  the  system   re-booted   because   of  the
          protection package? How frequently will this occur?
     How  much  additional  end-user  support  will  the  package
          require?

5. The probability that the package will remain in use?

     Will there  be any  interference or  usage requirements that
          will  discourage  the  user  from  keeping  the package
          active? (It won't be  effective if  they quickly desire
          to  de-install  it  and  perhaps  only pretend they are
          using it when management is present.)

6. Level of effectiveness it provides in combatting viruses.

     Will it be effective  against  viruses  produced  by someone
          with an experience level of:

          Level 1 - "Typical End User"? (Basic knowledge of using
                      applications and DOS commands.)
          Level 2 - "Power  User"?   (Knowledge  of  DOS  Command
                      processor, Hardware functions, BASIC
                      programming, etc.)
          Level 3 - "Applications  Programmer"?  (Knowledge of
                      programming languages and DOS service calls.)
          Level 4 - "Systems  Engineer"?  (Knowledge  of  DOS and
                      Hardware internal functions.)
          Level 5 -  "Computer  Science  Professor  that develops
                         viruses for research purposes"?

     Which types of intrusion will it be effective against?

          "Covert Entry"?
          "Overt Entry"?

     Does  it  detect  a  virus  attempting  to spread or "clone"
          itself?

     Does it  detect a  virus attempting  to place  itself into a
          position to be automatically run?

     If  a  virus  gets  into  the computer, which types of virus
          damage will it detect?

          "Massive Destruction"
          "Partial Destruction"
          "Selective Destruction"
          "Random Havoc Destruction"
          "Annoyance"

     Does the software detect a  virus  before  or  after  it has
          infected a program or made its attack?

     Does the publisher claim total protection from all viruses?


7. Does the software provide any assistance for "post mortem"
    analysis of suspected problems?

     ie:  If a virus symptom is detected and the computer is
     brought to a halt, is there any supporting information
     for analyzing the problem other than the operator's
     recall of events?


8. Impact on your machine's resources.

     How much RAM is used?
     Is any special hardware required?


9. Is the product compatible with:

     Your hardware configuration.
     Your Operating system version.
     Your network.
     Other software that you use, especially TSR's.

10.  Can  the  package  be  used  by  current computing personnel
     without substantial training?

     What type of computing experience is required to install the
          package?

11. Background of the publisher.

     References...  Who  is  using  this  or  other products from
          this publisher?  How is  this company  perceived by its
          customers? The press?

     How long has the publisher been in business?

     Was  the   product  Beta  Tested?...  By  valid,  well-known
          organizations or by friends of the company's owner?

     Was  the  product   tested   against   any   known  viruses?
          Successfully?

     What about on-going support? In what form? At what cost?

     Does the company plan to upgrade its product periodically?

     What is the upgrade policy? Expected costs?

12. Does  the package  provide any  other useful  benefits to the
     user besides virus protection?


=========================================================================
Date:         Mon, 26 Sep 88 00:20:37 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Loren K Keim   -- Lehigh University <LKK0@LEHIGH>
Subject:      Conference Concerns

Its been a long and bloody war.

Originally, I was told that an organization (ANY ORGANIZATION)
at Lehigh could aquire rooms to hold seminars.  This fact is
true, and in following such procedures, I proceeded to aquire
rooms with the okay of two campus organizations.

The Lehigh University Computing Center Staff complained about
this little conference.  I am told by people that specific
members of this list complained that such a conference would
make Lehigh look bad and the only purpose of the conference
is simply to show off my product.  I sincerely resent that.
I also resent the fact that I applied through the CSEE
department after concerns were lodged that the CSEE department
might sponsor the conference.  Bill Harris has stated that
Lehigh is not sponsoring it.  That has not yet been decided,
I simply have not asked the computing center to sponsor it.
I dislike the ideology of the center and have disagreed with
it publically on too many occations.

At this point in time, we are being asked to postpone the
conference for 8 months to a year.  We are being asked to
postpone it because Lehigh feels that the conference was
rushed and would make Lehigh look bad.  I disagree because
we had a slate of great people coming to discuss the
problems.   One of the conditions of the conference taking
place has also been that I do not participate in the
organization several people have told me.

In light of this, I have contacted all but two people who
sent checks to me and told them not to make any plane
reservations.  Anyone who has not heard from me, please
send me mail.

HOWEVER, since an overwhelming voice to continue the conference
elsewhere has been heard, we looked for an alternate place to
hold one.  Since all the hotels have been booked up, I am
volunteering one of my offices.   Since we won't have room for
speaches, and I suspect people will not want to come because
of these facts, I don't think we will have any speakers.

HOWEVER, since we do seem to have a good number of "experts"
coming, we have decided to have some meetings and get togethers
concerning the dangers of viruses to Banking systems and
secure systems, we would like to review the pro's and con's
of Fred Cohen's Complexity Based Security, several people's
CRC / encryption / and signature schemes, and I'd like people
to look over my own Separation Schematics if they would like.

I will post a list of who is coming later this week.

We will be getting together Friday night and Saturday of the
same weekend.

As I hear who still wants to come, this week I will be sending
out maps and hotel information (if anyone needs it) to those
interested at MY COST.

I will be returning those people's checks who sent them.  If
anyone wants to donate their checks to defer the cost of mailing
out maps and hotel info, as well as coffee and donuts, that is
fine, but it is completely unnecessary.

I would like to greatly thank those people who have helped so
much with this project, they have been a great support team.

I know we will already have a decent gathering of minds that
weekend, and I sincerely hope something comes out of the
meetings, whether that be some new security designs, some
new ideas, a new way of looking at the problem or anything.

Notes from the conference will be distributed to whoever might
want them, at cost of postage to sent them.

Again, thanks to all those people who have been a help in
getting this together.  Even we have been pushed off by the
Lehigh University Computing Center, I still think we will do
fine.

Thank you,

Comments please forward to LKK0@LEHIGH.

Loren K Keim
=========================================================================
Date:         Mon, 26 Sep 88 00:28:47 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Loren K Keim   -- Lehigh University <LKK0@LEHIGH>
Subject:      Conference Continued

A couple more items I seem to have missed looking at my notes.

As for those people who claimed I was setting this up for
my own benefit:  I don't want anyone to be unnerved by that.
We invited 4 other anti-viral software firms to send people,
and did not plan on showing our wares.

I'd also like to thank Dennis Director of Director Technologies
(Disk Defender) for volunteering his services.

I have been receiving a constant barrage of questions recently,
and I am very sorry if I missed replying to some.  Some I had
trouble getting to particular arpanet addresses, and some I
just didn't have time for, its been very hectic on this end.

For those two people I could not get in touch with (you know
who you are) that sent me checks for the conference.  I was
unable to contact each of you because I didn't receive
a bitnet address with your checks to my knowledge.  Likewise,
since Ken has elected to keep this a closed list, we can't
get a listing of those people on the list, something I
personally dislike.  Please contact me as soon as possible.

Anyone who received mail and hasn't gotten back to me,
I could really use replies from you.

Loren Keim
=========================================================================
Date:         Sat, 24 Sep 88 10:00:00 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         LYPOWY@UNCAMULT
Subject:      Virus Conference

I realize that this message doesn't necessarily belong here, but I was
unsure as to who I should be contacting, so this seemed like an
efficient way of finding out.

   It looks as if I am going to be able to make it to the Virus
Conference after all (because I am an undergraduate, I was forced to
find the funds for the trip on my own, and they appear to be coming
through).  What I need to know is the following:

          i) Am I too late? Is it still possible for me to make the required
             arrangements (I have flights booked, and my travel agent is
             looking into accomodation as we speak).

          ii) What exactly is the final schedule? I am basing my plans on an
              earlier version of the schedule.

          iii) Who should I be contacting with regards to more information on
               this conference?  (E-Mail that is, I have Ken's address around
               here somewhere).

                    Thanks for any help you can offer!

                              Greg Lypowy.
=========================================================================
Date:         Mon, 26 Sep 88 09:18:03 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Loren K Keim   -- Lehigh University <LKK0@LEHIGH>
Subject:      Virus Conference - Good News!

Well Folks,

Looks like some of my comments were a bit premature.  As the
majority of people writing to me have stated, they want the
conference to go on, full strength, as I would.

I was very afraid that we could not hold a full conference,
particularly having speakers for possibly as few as 20-25 people.
(We may have more, but this is our current count).  Everyone
else seems to think otherwise.

The general concensis is that the fewer people that attend,
the more dedicated the group, and the easier it may be for
people to make their oppinions known and discuss the topics
completely and possibly come up with something.

Some people suggested (something I hadn't thought of) that
we would also be a planning group for future conferences
in other parts of the country.  Its a good idea.  Most of
the conferences I've been to have been held for computer
hacks and others who know little to nothing about security
systems or virii other than what they've read in the trade
magazines.

In addition, we have located a country club we can rent rooms
from, and two schools have offered us some help, so I honestly
believr we will have room for speakers.  With this short a
number of people, I don't believe we'll be able to pay for
two of our possible speakers, BUT we have had a number of volunteers.

We have had a great deal of help from people and I thank you
all very much.  Especially I'd like to point out Joseph Sieczkowski,
(Did I spell it correctly?), Chris A. Bracy, William A. Bader,
and J.D. Abolins for their help and suggestions.  There are quite
a few others but I can't remember names off the top of my head.

We will be sending a full outline of the conference to the
list this afternoon.  (I have meetings all day and have some
changes I would like to make).

Those people who have already sent me checks:  Tell me whether
or not you are still coming.   If you are, I will be using those
checks to pay for rooms, the book which we have just about completed
putting together for the conference, and coffee/donuts.   We
should still have money left over and it will be refunded OR
we can take the group out to dinner.

I will be sending out hotel info and maps tommorrow morning to
those who are coming.

If you haven't sent me a check and you want to attend.
Please notify me at [e-mail] that you wish to
attend the conference (I'd like to get an exact head count
as early as possible), and send a check for $50.00 to
Computer Virus Conference, c/o Loren K Keim
PO Box 2423
Lehigh Valley, Pa. 18001

Again, a full outline to be sent probably about 6:00 or
6:30 tonight.

That's Eastern time.

Loren K Keim
=========================================================================
Date:         Mon, 26 Sep 88 16:37:30 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         SHERK@UMDD
Subject:      Conference Continued
In-Reply-To:  Message received on Mon, 26 Sep 88  09:40:04 EDT

>since Ken has elected to keep this a closed list, we can't
>get a listing of those people on the list, something I
>personally dislike.

>Loren Keim
I am glad it is closed! I would be very upset if my name appeared on
a junk mailing list.
=========================================================================
Date:         Tue, 27 Sep 88 01:21:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         me! Jefferson Ogata <OGATA@UMDD>
Subject:      Re: 2 years probation

>>Probation is a breeze.
>Is that from personal experience?

heh heh. yup. of course, you knew that, Eric.

By the way, I think it will be easy for Burleson to find another
job, as long as his name is not too widely publicized.  Of course,
this depends on whether the conviction is a felony conviction or
a misdemeanor conviction.  With a sentence like two years probation,
it sounds like a misdemeanor.  Most employers are not very concerned
about misdemeanor convictions.

- Jeff Ogata
=========================================================================
Date:         Tue, 27 Sep 88 08:29:40 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ken van Wyk <[e-mail]>
Subject:      Re: Conference Continued
In-Reply-To:  Your message of Mon, 26 Sep 88 16:37:30 EDT

> I am glad it is closed! I would be very upset if my name appeared on
> a junk mailing list.

Actually, the list is quite open; anyone who wants to be on the list
can be on the list (as long as they abide by the guidelines).  The
list of subscribers, however, is not available for public perusal, for
just the reason mentioned above.

Regarding the Burleson case, I believe that the AP article said that
he was convicted of a third degree felony.  I'd imagine that would
make it at least a bit difficult for him to get a job with a reputable
firm.

Ken




Kenneth R. van Wyk                   Calvin: I'm gonna learn to ride this bike
User Services Senior Consultant         if it kills me! ...  AAAAAUUUGGGHHH!!!
Lehigh University Computing Center   Hobbes: Did it kill you?!
Internet: <[e-mail]> Calvin: No, it decided to maim me first.
BITNET:   <LUKEN@LEHIIBM1>
=========================================================================
Date:         Tue, 27 Sep 88 14:39:10 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ken van Wyk <[e-mail]>
Subject:      Pennsylvania Legislative virus recommendations

I just received a copy of the Pennsylvania Legislative Budget and
Finance Committee's paper, "Study of Computer 'Viruses' and Their
Potential for Infecting Commonwealth Computer Systems", which was
released on September 21, 1988.  While I haven't had too much time to
read it thoroughly yet, it seems as though the Committe spent a lot of
time on it, and that it could be of value.

The report starts by defining what a virus is and how a virus can
spread.  It then categorizes the different types of known viruses and
discusses methods for prevention, detection, and recovery from
viruses.  Next, it analyzes what the Commonwealth (of PA) is currently
doing to prevent, detect, and recover from a virus.  Finally, it
presents additional action that may be warranted to prevent, detect,
and recover from viruses.

To summarize the conclusions of the Committee:

1) They recommend that "All Commonwealth agencies which utilize
computer systems such as personal computers, minicomputers, and
mainframe computers should formally assess the risk of each computer
system against the infection from computer viruses."

2) "All Commonwealth agencies utilizing any form of electronic data
processing (EDP), including personal computers, minicomputers, and
mainframe computers, should establish routine backup procedures (at
least on a weekly basis) for all active files and programs.  Backup
copies of the agency's files and programs should be maintained in a
secure location for several months since a virus could lay dormant for
an extended period of time."

3) "The Commonwealth, through the Bureau of EDP/Telecommunications
Technology, should establish formally written policies on obtaining
and using computer software."  These include guidelines for software
sharing and copying (including via modem), "restrictions on obtaining
software from unknown or secondary sources, such as associates, peers,
or in the mail through an unfamiliar vendor", restrictions on the use
of electronic bulletin boards, and "strict internal controls over
access to computer programs and files by EDP users."

4) "Commonwealth agencies using computer systems should conduct
computer security awareness training for EDP users."

5) "Commonwealth agencies should also establish a formal procedure for
testing existing computer files and programs for the presence of
computer viruses using methods as anti-virus software, using
'checksums' prior to running a program, and developing in-house
programs to check for unexpected access to programs and files."

6) "Commonwealth agencies which have identified highly sensitive data
should explore the feasibility of using encryption to protect against
virus infection."  They include in this encryption of binaries such
that "any unauthorized changes to the program would result in it being
unusable."

7) Revisions should be made to "Disaster Recover Plans for
Commonwealth agencies to include provisions for the recovery from the
infection of a computer virus."

8) "Since computer viruses are not specifically defined in the PA
computer crime statue, the General Assembly should consider amending
state law to specifically define each type of action which would be
considered a computer crime and also amend the statute to directly
relate the penalty imposed to the damaged suffered as a result of the
computer crime."

9) "The General Assembly should consider enactment of legislation to
require and encourage state agencies to develop and implement
effective computer security plans and procedures."


Any opinions?


Ken



Kenneth R. van Wyk                   Calvin: I'm gonna learn to ride this bike
User Services Senior Consultant         if it kills me! ...  AAAAAUUUGGGHHH!!!
Lehigh University Computing Center   Hobbes: Did it kill you?!
Internet: <[e-mail]> Calvin: No, it decided to maim me first.
BITNET:   <LUKEN@LEHIIBM1>
=========================================================================
Date:         Tue, 27 Sep 88 15:24:00 CST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         James Ford <JFORD1@UA1VM>
Subject:      Virus strikes Tuscaloosa.

Well gentlemen (and women), it seems that a virus has struck Tucsaloosa and
I've been called on to try and help.  I haven't seen the infected computers
yet, but here is a discription of what I do know.

              1)  The FAT that points to valid data space corrupted.
                  It shows one giant corrupted file.
              2)  All data has been overwritten with FF(hex)

The computers are backed up once a week, so there is a copy of the data
that was lost.  However, transactions since then are not recorded.  Is
there any way to recover the corrupted data?  (I believe that they were
using COMPRESS, MIRROR and PCBACKUP to back up the files...)

Any hints on what this problem might be?  Its rather important to find out,
since the affected facility is in the health field.

Any comments/hints/suggestions would be appreciated.

                          James
=========================================================================
Date:         Tue, 27 Sep 88 21:42:39 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Loren K Keim   -- Lehigh University <LKK0@LEHIGH>
Subject:      Conference Speaches Outlined

Here's a quick outline of the speaches to be held at the
conference.  Any questions or suggestions (as we've had
several people ask to discuss telecommunications concerns
and ATM concerns) we'll review and try to accomodate.

SPEACHES
--------


What are Viruses?
-----------------

What are viruses?   Where do they  come   from?  Reviews of  different
forms they take, including Boot Sector Viruses, .EXE viruses, Unix and
VMS viruses.  Reviewing the Lehigh, Yale, Brain, Christmas, and Israeli
viruses.


Tracking Computer Viruses
-------------------------

How several organizations track virus writers.


Computer TapeWorms
------------------

Reviewing the Xerox research on Computer Worms and their dangers.


Computer Security Concerns I
----------------------------

Are schools in real danger of losing research?  How can we protect
businesses and colleges from the dangers?


Computer Security Concerns II
-----------------------------

System Integrety in large networked environments.  Government security
systems, banking systems, and virus defense designs.  Included will be
Limited    Transitivity  models,  Limited   Functionality  ideas,  the
Bell-LaPadula  Model, the   Biba  Model, and   the  Complexity   Based
Functionality Model.   Future concerns will be discussed.


Future Virus Concerns
---------------------

The ease in which a complicated virus could attack our banking
systems and major industries.  How we will stop these happenings.
AT&T's new defense models and other companies packaging software
protections with their programs.



PANEL DISCUSSIONS
-----------------


Panel Discussion on Current University Computer Concerns
--------------------------------------------------------

Several panelists from different anti-viral companies will
be discussing this.

Suggested:
---------

Panel discussion on ATM networks and telecomunications.


DEMONSTRATIONS:
--------------

Demonstration of the various anti-virus program by their respective
companies will take place.

A demonstration of a tape worm will be performed.

A demonstration of Unix System viruses will be performed.


ROUND TABLE DISCUSSIONS:
-----------------------

People would be free to discuss viruses and computer security concerns
with each other, and freely introduce themselves.

We've also been asked to hold sessions concerning banking systems
and the danger to ATM networks, and the danger to networking in
general and telecommunications.


PAPERS:
------

A variety of papers and books will be available for free and
for sale.

BOOK:
----

A book with copies of some of the speaches given, and several articles
on viruses, computer  security, encryption schemes,  and  computer law
will be printed and distributed to those who show up.  We will include
a  paper on  worms, a paper  on virus-like  games, a  detailed look at
security models / their uses and  limitations, a full listing of known
viruses / psuedocode breakdowns / possible defenses.

=========================================================================
Date:         Wed, 28 Sep 88 01:07:20 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David A. Bader" <DAB3@LEHIGH>
Subject:      Time Magazine article

The story on viruses in the latest issue of Time Magazine has spurred a
LOT of conversation on this local area's Bulletin Board Systems.  Of
the half-dozen that I have been logged into tonight, MOST have had
conversation regarding the integrity of their files, and also different
scare stories of "other viruses."

David A. Bader
DAB3@LEHIGH
=========================================================================
Date:         Wed, 28 Sep 88 09:39:26 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Conrad Jacoby (DC)" <JACOBY@YALEVM>
Subject:      Book from virus conference

Hi there!!

    Is there any way that the book mentioned in Loren's description of the
upcoming virus convention could be made available to the more general public?
I and the people I work for would be very interested in such a volume.  And
obviously, we'd pay money for it.


-------------------------------------------------------------------------------
Conrad J. Jacoby                       P.O. Box 3805 Yale Station
Yale University                        New Haven, CT 06520
Sterling Memorial Library              [phone]

"Generalist at Large"                  [e-mail]

-------------------------------------------------------------------------------
=========================================================================
Date:         Wed, 28 Sep 88 08:47:00 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David D. Grisham" <DAVE@UNMB>
Subject:      Real (Conference Proceedings)

Sorry for the last piece of unintended mail.  (a stuck  buffer)
Anyway-
I personally would like to place a request early, for the "book"
of papers, etc. that Loren referred to in her last letter.
I imagine that I am not the only one who does not have the travel
funds, but can spring for the proceedings.
Dave
=========================================================================
Date:         Wed, 28 Sep 88 15:49:43 PDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         David Voss <FB.DFV@STANFORD>


>Well gentlemen (and women), it seems that a virus has struck
>Tucsaloosa and
>I've been called on to try and help.  I haven't seen the infected
>computers yet, but here is a discription of what I do know.
>
>              1)  The FAT that points to valid data space
>                  corrupted.
>                  It shows one giant corrupted file.
>              2)  All data has been overwritten with FF(hex)
>
>The computers are backed up once a week, so there is a copy of the
>data
>that was lost.  However, transactions since then are not recorded.  Is
>there any way to recover the corrupted data?  (I believe that they
>were using COMPRESS, MIRROR and PCBACKUP to back up the files...)
>
>Any hints on what this problem might be?  Its rather important to
>find out, since the affected facility is in the health field.

       By 'corrupted data' do you mean FAT data?  Your note
       is a bit ambiguous. Is it the FAT that has been
       overwritten with FF hex?

       If just the FAT (file allocation table, of which DOS
       maintains two copies, by the way) is destroyed, you can
       use CHKDSK to collect the data into a series of files
       (named FILExxxx.CHK, where xxxx is a sequential number)
       that can then be scanned with something like the Norton
       Utilities.  This only is effective with clear ASCII text,
       not compressed files.  The data can be recovered, but
       it takes work.

       If, however, the data has been overwritten there is no
       hope of recovery.  Data entered after the last backup
       is gone.

       The problem could be a virus, or it could be something
       else.  It's important to isolate the software that was
       being used during the crash and check against master
       copies.

       -- David Voss [fb.dfv@stanford]

=========================================================================
Date:         Wed, 28 Sep 88 20:20:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Santanu Sircar <SSIRCAR@UMAECS>
Subject:      FSP_12

Does anyone have an ARC-ed version of Flu-Shot v1.2?  I was not able to
correctly decode FSP_12.UUE which I received from LISTSERV@LEHIIBM1. Thanks.

        -Santanu Sircar-
        (SSIRCAR@UMAECS)
=========================================================================
Date:         Wed, 28 Sep 88 20:27:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      RE: FSP_12

FSP_12 IS VERY BUGGY.  WHY NOT TRY FSP_14?

-David


/-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-\
|    From:  David A. Bader, Studentis Maximus                             |
|                                                                         |
|    DAB3@LEHIGH                       SloNet: 1402 Lorain Avenue         |
|    [e-mail]                Bethlehem, Pa.  18018      |
|    HACK![e-mail]                                   |
|                                                                         |
|    SchoolNet: Box 914,               -On a mostly harmless              |
|            Lehigh University,         blue green planet...              |
|          Bethlehem, Pa.  18015       -And loving it!                    |
\________________________________________________________________________/
=========================================================================
Date:         Thu, 29 Sep 88 13:08:21 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Neil Goldman <NG44SPEL@MIAMIU>
Subject:      Re: FSP_12
In-Reply-To:  Message of Wed, 28 Sep 88 20:20:00 EDT from <SSIRCAR@UMAECS>

>Does anyone have an ARC-ed version of Flu-Shot v1.2?  I was not able to
>correctly decode FSP_12.UUE which I received from LISTSERV@LEHIIBM1. Thanks.
>
>        -Santanu Sircar-
>        (SSIRCAR@UMAECS)

It is my understanding that as of early August, Ross Greenberg (the author
of FluShot+) was working on a new version, which at that time was in beta test.

Any versions prior to that have numerous bugs, as has been outlined previously
in this forum.

Neil A. Goldman                        [e-mail]

Replies, Concerns, Disagreements, and Flames expected.
Mastercard, Visa, and American Express not accepted.
=========================================================================
Date:         Thu, 29 Sep 88 18:13:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      RE: Re: FSP_12

My verion of FluShot Plus is dated 7-13-88, and I have been using it
in my system daily since about 7-18-88. There are only two bugs
that *I* have caught so far, neither of which are fatal, but just
annoying. The first deals with reading and writing to a floppy drive (in
my AT clone, I set the option to check CMOS, and FSP_14 warns me that CMOS
is being changed - why? I don't know.), and the second problems is a "whole"
in FSP_14's protection that lets protected files be read and modified with
unstandard text editors.

  -David



/-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-\
|    From:  David A. Bader, Studentis Maximus                             |
|                                                                         |
|    DAB3@LEHIGH                       SloNet: 1402 Lorain Avenue         |
|    [e-mail]                Bethlehem, Pa.  18018      |
|    HACK![e-mail]                                   |
|                                                                         |
|    SchoolNet: Box 914,               -On a mostly harmless              |
|            Lehigh University,         blue green planet...              |
|          Bethlehem, Pa.  18015       -And loving it!                    |
\________________________________________________________________________/

=========================================================================
Date:         Fri, 30 Sep 88 01:24:55 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Loren K Keim   -- Lehigh University <LKK0@LEHIGH>
Subject:      Conference Book / Phone Number

I've had a number of people ask if the book would be
available for sale after the conference.  Yes, we'll
send out copies to whoever might want one, including
notes we'll take from each lecture and discussion we
can.

I can't quote a price yet, we'll need to know exact
printing costs (although I can come close) and shipping.
I'll get that to you probably a few days before the
conference, but it is helpful for me if you send me
a letter saying you want one.

LKK0@LEHIGH

Also, many people have been having problems getting hold
of me.  I will be at my father's house for till Oct. 31st
(my house is being worked on at this very moment) which
is [phone].   You'll have to ask for Jr because we
have the same name.  You can still leave a message on my
machine at my place [phone], and I will get it.
During the day, its easier to leave a message at our main
office [phone].

Loren
=========================================================================
Date:         Fri, 30 Sep 88 10:21:59 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Otto Stolz [phone] <RZOTTO@DKNKURZ1>
Subject:      re: legislation on viri

There have been questions in this list concerning laws pertinent to
virus writing and implanting, and related issues.  This contribution
tries to give an answer for the Federal republic of Germany.
As I'm no lawyer, and English isn't my mother tongue, you'll probably
need much imagination to understand my attempts for proper translation
of the legal terms (this Cassel's Dictionary doesn't serve its purpose,
either).

Paragraph (+) 303 of our Penal Code deals with Damage to Property.
After this paragraph, there have been inserted two more paragraphs,
effective from 1 Aug 1986:

  + 303a Alteration of Data:
  (1) Who illegally deletes, suppresses, renders useless, or alters Data
      (cf. +202a, sect. 2), will be punished with up to two year's impri-
      sonment or with a fine.
  (2) The attempt is punishable.

  + 303b Computer-Sabotage:
  (1) Who disturbs data processing that is of significant importance
      to some outside firm or some public authority by ways of
      1. an act according to +303a sect. 1    or
      2. destroying, damaging, rendering useless, removing, or
         altering some data processing unit or some data recording
         medium,
      will be punished with up to five year's imprisonment or a fine.
  (2) The attempt is punishable.

Implanting a virus into a program on someboy else's computer or diskette
means changing data, illegally, and hence clearly is subsumed under
+303a sect. 1.  Putting into circulation a Trojan Horse that is meant
to implant some virus, clearly is subsumed under +303a sect. 2.
In both cases, +303a is applicable even if no damage has been caused.

+303b sect. 1 nr. 1 heightens the punishment for qualified cases of
Alteration of Data, whilst +303b sect. 1 nr. 2 does the same for
qualified cases of Damage to Property.  The latter will seldom apply
to viri -- only if a virus damages the screen (which can be done by
faulty or malicious programming of the CGA or EGA cards, as I've been
told) or other hardware.

In any case, it'll be difficult -- if not impossible -- to hold somebody
responsible for virus-issuing.  E.g. we have evidence that the virus
we've found, recently, has been dwelling in some of our computers for
more than three months.  We surely will not be able to trace this
virus back to its originator!

I do not know what the term "illegally" in +303a means to lawyers.
Hopefully, a person spreading a virus unwittingly cannot be blamed
for "illegally altering data".

There is also a "Law on Protection from Improper Use of Person-Related
Data during Data Processing" (do not blame my translation: this is also
awful German :-), effective from 1 Jan 1978 (for data processing by
private persons, corporations, firms, and federal authorities) and
a couple of similar laws (for data processing by municipal, regional and
other authorities).

Here, I cannot discuss the whole law.  It pertains only to particulars
(no statistical aggregations) of individuals (no corporate bodies).
It covers every form of data processing, even manually processed
card-indizes.  According to this law, processing of personal data is
in principle forbidden (i.e. only allowed in special cases enumerated
by this or other laws).  One special case is consent of the person
refferred to ( and I take it for granted, that posting a note to
VIRUS-L implies everybody's consent to being refferred in every
subscriber's NOTEBOOK and NAMES files -- otherwise I'd be liable
for breaking this wonderful law :-)

Now for the implication of this law to virus-defeating:  according to
+6 (far too long to be quoted verbatim) technical and organizational
measures are to be taken to prevent unauthorized disemination or
alteration of person-related data.

Under this paragraph, a faculty member of our university had to give up
processing his reserch-data (which included criminal records and similar
data of real persons) on a personal computer.  Even if this computer was
kept in a locked room, it was considered too weak (subject to unautho-
rized and unnoticed manipulations) to bear such delicate personal data.
The research-project was delayed until a new and safe data processing
procedure (on a host) had been established.

So much for "security": word has spread even to lawyers in our country,
that there is *no* such thing as "Security on a Personal Computer"!

Best regards to everybody.  I agree, that you store my name, phone
number, and BITNET address on your computer with the object of
communication :-)
                  Otto Stolz
=========================================================================
Date:         Fri, 30 Sep 88 10:30:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Santanu Sircar <SSIRCAR@UMAECS>
Subject:      RE: Re: FSP_12

To send any file(s) to anyone, type the following:
        -For a binary file
                SEND/FILE filename username@host /VMSDUMP
        -For a text file
                SEND/FILE filename username@host

                -Santanu
=========================================================================
Date:         Fri, 30 Sep 88 11:02:48 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ken van Wyk <[e-mail]>
Subject:      RE: Re: FSP_12
In-Reply-To:  Your message of Fri, 30 Sep 88 10:30:00 EDT

> To send any file(s) to anyone, type the following:
>         -For a binary file
>                 SEND/FILE filename username@host /VMSDUMP
>         -For a text file
>                 SEND/FILE filename username@host

That works great...if you're on a VAX on BITNET running JNET, and
binary files can only be sent to another BITNET host using the above
method.  For the rest of us, however, that command will only generate
an error message.

To send a binary file via the networks, the (arguably) most universal
method is to uuencode the file and mail it to the other user(s).  The
recipient(s) would then uudecode the file back into its original
binary form.

I've been meaning to get onto Ross Greenburg's bboard and pick up his
latest version of FSP (I believe 1.4 or 1.5).  When I get it, I'll
make the file available via the LISTSERV here at Lehigh.  (Please don't
send me the file, I'll get it directly from Ross to assure that it's
the latest version.)

Ken




Kenneth R. van Wyk                   Calvin: I'm gonna learn to ride this bike
User Services Senior Consultant         if it kills me! ...  AAAAAUUUGGGHHH!!!
Lehigh University Computing Center   Hobbes: Did it kill you?!
Internet: <[e-mail]> Calvin: No, it decided to maim me first.
BITNET:   <LUKEN@LEHIIBM1>
=========================================================================
Date:         Fri, 30 Sep 88 18:48:17 +0200
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Y. Radai" <RADAI1@HBUNOS>
Subject:      Misc. remarks

  For various reasons (Bitnet problems, local holidays, even occasional work!)
I'm only now catching up with the correspondence on VIRUS-L.  So please forgive
me if I refer to postings which are 2-3 weeks old.


  EAE114@URIMVS (ERISTIC) writes:
> Has anybody seen or heard of any virus designed to pass a CRC
> check? Or is this more work than the casual psychopath
> is willing to incur?

  I haven't heard of an actual virus which does this, but not long ago I re-
ceived an interesting program called PROVECRC, distributed by Chuck Gilmore of
Gilmore Systems, CA, which is supposed to demonstrate what a virus *could* do
in this respect.  Given any input file (25 to 32000 bytes long), this program
produces another file of the same size which, though different in content, is
supposed to have the same CRC.  The moral is supposed to be that "CRC checking
alone is inadequate for file modification detection."
  Obviously, Gilmore's program could not possibly succeed against *arbitrary*
generating polynomials; he would have to know the actual generator, or at least
know that the generator was one of a certain small set of polynomials.  The
evidence shows that he assumes a specific 16-bit generator.
  In order to test his program, I ran PROVECRC on a small file.  As promised,
the modified file which was created had the same size, date and time as the
original file.  But when I computed the CRC of each of the two files using one
of the CRC programs at my disposal, the CRCs were *different*.  The same thing
happened when I tried another CRC program.  Presumably, they don't use the same
generator as Gilmore assumed.
  By comparing the files, I discovered that what PROVECRC does is as follows:
Let n be the size of the file.  Then it replaces the (n-19)th through (n-11)th
bytes of the file by the string '*altered*' and twiddles the (n-10)th and
(n-9)th bytes so as to yield the same CRC as the original file (relative to
whatever generator he was assuming).
  I repeated the experiment with other program files, getting the same results
with respect to CRCs.  It is not surprising that in some cases the modified
versions of the programs performed exactly as the original programs did, since
for many executable files the actual program ends considerably before the nth
byte, so that PROVECRC had enough room to modify bytes without affecting exe-
cution.  Of course, actual viruses that perform destructive actions would gene-
rally take up more space than is available in such a "gap".
  But what most aroused my curiosity about PROVECRC was this:  After an initial
message giving the "actual" CRC of the file, one gets the message "NOTE: Up
to 65,535 passes may take place!"  The actual number of passes depends somehow
on the particular file, though it's not a function of the size of the file.  In
any case, each pass takes about 1/65 of a second on the 4.77 MHz PC I was using.
But what precisely was the program doing all this time and what constitutes a
"pass"?  Given that the program (thinks it) knows the generator and the corres-
ponding CRC of the file, I don't think it should take that much time to figure
out what 16 bits should replace the (n-10)th and (n-9)th bytes.  (I considered
the possibility that the mention of passes was merely a coverup for some time-
consuming Trojan or viral activity, but I found no indication of it.)
  So does anyone out there have any idea whether there's a legitimate reason for
such a program to take so much time, and what a "pass" might consist of?  (If
anyone's interested in taking this program apart, I'll be glad to e-mail it to
him.)


   me!Jeff Ogata writes:
>The reason I discussed only adding bytes to the original file, rather
>than modifying bytes in the file, is that as far as I know, virus
>attacks are not effective if they crash the program they infect,
>which is likely to happen if they twiddle bits in the original
>program.

  As Jerry Leichter replied, modification with preservation of size can be
performed without crashing the program if the virus writer concentrates his
attack on specific files whose content is known to him in advance.  But I wish
to add another point:  Any self-respecting program to compare checksums of
files will also compare their *sizes*.  (And there are some programs which no-
tify you of size changes even though they don't compute any checksum.)  There-
fore a virus creator has a better chance of his modification going undetected if
he avoids altering the file size.


  Referring to the Kiel-Lee paper "The Infection of PC Compatible Computers",
David Chess writes:
> In a similar vein, I would advise being a little less confident
> when stating things like "four versions of the Israeli virus
> and seven versions of the Brain virus have been found."  It
> may be true in the most literal sense of "version" (anyone could
> create a "new version" of one of these by changing a text or
> no-op byte), but there doesn't seem to be any good evidence
> that it's *really* true, in the sense of there being that many
> versions that actually have some difference in their behavior.
> (Authors, especially in the popular press, always seem to be
> tempted to exaggerate, if only by implication, the number of
> different viruses they know of; makes them sound wiser...)

  I suspect that when the authors spoke of "four versions of the Israeli virus",
they meant to say "four Israeli viruses".  And I can assure you, David, that
there really are (at least) that many.  I agree that using a binary editor to
change a string of text, or even to change the date the bomb is set to go off,
should not be considered as creating a new virus (although the latter could be
considered as a new "version" of the same virus since it changes the *behavior*
in an essential way).  But the two viruses discovered in Israel whose target
date is April Fools Day are sufficiently distinct from the Friday-the-13th virus
and from each other that they deserve to be considered as separate viruses.
(The fourth virus is admittedly very similar to the main Friday-the-13th virus
and maybe should be considered as another version of the same virus, but if I'm
not mistaken, even it differs by more than mere binary editing.)

                                           Y. Radai
                                           Hebrew Univ. of Jerusalem
=========================================================================
Date:         Fri, 30 Sep 88 14:40:05 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         MICHAEL LEE <CM10@WUBLUE>
Subject:      Re: Conference Speaches Outlined



And where is Lehigh University?

                                   Mike Lee
                                   Washington U.
                                   St. Louis, Mo

=========================================================================
Date:         Fri, 30 Sep 88 14:43:58 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         MICHAEL LEE <CM10@WUBLUE>
Subject:      Re: Conference Speaches Outlined



I received information about a conference being given about viruses and
security concerns.  Where will this lecture/conference be taking place?
I am interested in attending.

                                                 ----mike lee

                                                     Washington U
=========================================================================
Date:         Sun, 2 Oct 88 19:12:14 MEZ
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Konrad Neuwirth <A4422DAE@AWIUNI11>
Subject:      MOIN EXEC

I am not sure if all of you have heared about it, so here i go!

On our net(s) a program called MOIN EXEC is loose. To the user
it looks like a super CHAT program with a answering machine, you
know that thing that says: I am not here.. . But in fact there
is some sort of power user coded in, whom it is allowed to execute
ANY CMS Command on an account running MOIN EXEC. It is already
forbidden to run MOIN EXEC, and the same program under other names,
The charge is loss of acoount, and even ``legal steps''.

Remember. If anyone offers you MOIN EXEC, or anything he discribes
as a super Chat, be extremely careful.


                               SIGNED, AS ALWAYS
                                     I /I  +----
                                     I  I  +--
                                     I    I  +----
 "SORRY FOR LIVING, I WILL NEVER DO IT AGAIN"
                    KONRAD NEUWIRTH (A4422DAE AT AWIUNI11) (KONRAD ON RELAY)
=========================================================================
Date:         Sun, 2 Oct 88 22:20:00 MST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Michael Kielsky <AGMGK@ASUACVAX>
Subject:      Please send data...Please???


     Dear Computer Professional:

     I am currently in the process of developing research for a
     thesis.  The topic of this research is "Computer Security in
     the Manufacturing Environment".

     I am seeking your assistance in obtaining information
     relevant to this topic, as there currently exists no
     published data. Specifically, I would like to reach people
     in industry who have involvement in Computer Integrated
     Manufacturing (CIM), and related fields, and would be
     willing to provide me some information on their experiences
     with computer security in that environment.

     Helpful information would include policies and procedures
     (current or past), actual experiences, etc., regarding
     Computer Security (in its broadest interpretation),
     implemented specifically in the Computer Integrated
     Manufacturing (CIM), process control, and related
     environments.  Suggestions gladly considered.

     The data obtained will be compiled and published in Spring
     1989, as my master's thesis.

     I can be contacted as follows:

         work:                       home:

             Michael Kielsky             1902 E. St. Catherine
             Sr. Software Engineer       Phoenix, AZ  85040  (USA)
             TAG Software                [phone]
             5420-100 W. Camelback
             Glendale, AZ  85301  (USA)
             [phone] or 242-9401
             [phone] (Fax)

         or via electronic mail:

             BITNET address:  AGMGK@ASUACVAX

     If you know of anyone else who might be able to help me out,
     please feel free to pass along a copy of this letter.

     Your help will be appreciated.

     Michael Kielsky

=========================================================================
Date:         Sat, 1 Oct 88 20:20:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      Re: 2 years probation
In-Reply-To:  Message of 27 Sep 88 01:21 EDT from "me! Jefferson Ogata"


Jefferson Ogata says:

>By the way, I think it will be easy for Burleson to find another
>job, as long as his name is not too widely publicized.  Of course,

"Crazy Stanley" was convicted of a felony, served time in jail, and then
was elected a director of a professional organization.  So much for the
enlightened self interest of the computer fraternity.

Bill Murray
=========================================================================
Date:         Tue, 4 Oct 88 14:11:15 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David A. Bader" <DAB3@LEHIGH>
Subject:      TRAPDISK

I found a new TSR utility floating around to protect disks from
random INT 13h read/writes etc. Anyone hear of this program or have any
comments?

-David Bader
 DAB3@LEHIGH
-----------------------------------------------------------------------
                                TRAPDISK.COM
                                Version 1.0

                                  PURPOSE

"Trap Disk" (TRAPDISK.COM) is NOT a game!  It is a further attempt to
prevent pranksters from destroying your data.  The proliferation of the
"Trojan Horse" type programs which proport to be games but actually plant
bombs in your system which format your hard disk or erase the disk
directory, has prompted the writing of this program, as well as
CHK4BOMB.EXE ("Check for Bomb").  This program is based on BOMBSQAD.COM by
Andy Hopkins.

CHK4BOMB.EXE reads the program file from disk and attempts to spot dangerous
code and suspicious messages, but since code is often a function of run
time memory situations, it could miss spotting the "bombs".

TRAPDISK.COM is a program that intercepts calls to the BIOS code in ROM as a
suspicious program is run, displays what is going to happen during the
call, and asks if you want to continue.  You can abort or continue as you
see fit.

                   INSTRUCTIONS FOR RUNNING TRAPDISK.COM

Type "TRAPDISK" and one or more of the following letters (upper or lower):
  "R"         to stop on a request to READ a sector
  "W"         to stop on a request to WRITE to a sector
  "V"         to stop on a request to VERIFY a sector
  "F"         to stop on a request to FORMAT a track
  "U"         to 'UNINSTALL' TRAPDISK - note that program will not be
              active, but memory can not be reused until the system
              is rebooted.
  "H" or "?"  to display a brief command summary (will not install
              TRAPDISK).

To change any of the instructions, just run the program again with the new
letters;  although TRAPDISK is a memory-resident program, once
installed it will not attempt to re-install itself.

Remember that TRAPDISK will stop only on those requests specified the last
time it was invoked.  If you start it with "F" only to stop on a FORMAT
call, and later want to add "W" to stop on a WRITE call, you must specify:
TRAPDISK FW on the DOS command line.

IF NO LETTERS ARE SPECIFIED:  TRAPDISK will remain active but will not stop
on any disk calls.  If TRAPDISK is not installed, a "blank" call will
install it in memory.

SUGGESTION: Try TRAPDISK R to stop on a READ request and then try a DIR
command.  Watch the operation on TRAPDISK when disk READS are called.  This
will give you an indication of how the program works.



                                 MESSAGES

When TRAPDISK detects a call to the BIOS routines, it checks to see if the
stop condition is met.  If the function has not been selected,  TRAPDISK
will pass control directly to the BIOS disk routine.  If, however, a stop
has been requested before a disk function occurs, TRAPDISK will display the
following message:

                   |--------------------------------------|
                   |            DISK MONITOR              |
                   |--------------------------------------|
                   |      Break on request to READ        |
                   |                                      |
                   |  DRIVE  HEAD  TRACK  SECTOR  NUMBER  |
                   |    A:     0     26     1       9     |
                   |     Data address    0BA9:00F0        |
                   |     Return address  0070:0143        |
                   |                                      |
                   |  <Esc> to Abort  <Ret> to Perform    |
                   | <Del> to perform & disable trapdisk  |
                   |--------------------------------------|

DRIVE          is the requested drive (A-D).
HEAD           is the side or head (0-1) for diskette (0-3 or more) for
               hard disk.
TRACK          is the cylinder or track in decimal (0-39 or more).
SECTOR         is the starting sector number in decimal (1-8 or 1-9 or
               more).
NUMBER         is the number of sectors involved in the operation.
DATA ADDRESS   (in HEX) is where the data is stored or read from.
RETURN ADDRESS (in Hex) is the return address for the calling program (i.e.
               the address where execution will resume after Int 13
               completes).

PRESSING THE ESCAPE KEY causes TRAPDISK to return to the calling program
with the error code for time out.  The disk operation is NOT performed.
The action the program may take on this error will vary, but the requested
disk function will NOT take place.

PRESSING THE RETURN KEY causes the program to carry on as if TRAPDISK did
not exist for this call.  Be warned that if you request a stop on a READ
operation, you will press the Return key many times just to read one file
as DOS searches directories and the FAT!  Instructive, but not too useful.

PRESSING THE DEL KEY causes the program to carry on (just like RETURN), but
there is a difference.  DEL will shut down any further checking.  The only
way to enable checking again is to call TRAPDISK with command-line
arguments (as described above).  This key is very useful in cases where you
have forgotten that TRAPDISK is installed and want to disable it so you can
get on with your work!


                 CHANGES & IMPROVEMENTS versus BOMBSQAD.EXE

"TRAPDISK" has added a command-line help that functions without installing
the resident code.  It corrects a bug in "BOMBSQAD" that incorrectly
reported hard disk drive letters.  It extends the BIOS calls beyond the
diskette interrupt calls to some of the hard disk specific calls (Read
Long, Write Long, Format Bad Sector, Format Whole Disk) that "BOMBSQAD"
does not handle.  And it has added the "RETURN ADDRESS" information and the
"Del" key to the pop-up window.


                              TECHNICAL NOTES

This program can only trap access requests that go through Int 13h.
All of the DOS disk calls for standard disk/diskette devices are routed
through this interrupt.  However, access to installed devices (like some RAM
disks or OEM add-on packages like TALLGRASS & SYSGEN) is often through
vendor-sipplied device drivers.  These drivers are known to DOS and are
used in lieu of Int 13h to access these devices.  TRAPDISK CAN ONLY CAPTURE
ACCESS REQUESTS FOR DEVICES THAT ARE CONTROLLED VIA INT 13h!!!  Ergo, any
"devices" that use installed device drivers could be compromised by a well-
placed trojan horse program, even if TRAPDISK is active.

The moral: DO NOT depend on TRAPDISK to protect your add-on hard disks from
damage from a trojan horse algorhythm!


                        COPYRIGHT AND DISTRIBUTION

In the spirit of Mr. Hopkins original program, feel free to copy and
distribute this program.  We make no claim on any sort of copyright, since
this program is based on BOMBSQAD!
-----------------------------------------------------------------------
=========================================================================
Date:         Tue, 4 Oct 88 14:56:18 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ken van Wyk <[e-mail]>
Subject:      Re: TRAPDISK
In-Reply-To:  Your message of Tue, 4 Oct 88 14:11:15 EDT

> I found a new TSR utility floating around to protect disks from
> random INT 13h read/writes etc. Anyone hear of this program or have any
> comments?

There are a few big problems with just trapping INT 13h.  First, it's
rather easy to circumvent.  Also, almost all programs (if not all!)
that read/write to, for example, data files use INT 13h either
directly or indirectly via DOS INT 21h calls.  Trapping out every
sector read or write can get downright annoying to the user.  To
illustrate this, try setting TRAPDISK to stop all disk writes, and
then use your favorite editor to edit *and save* a large text file.
You will slowly watch TRAPDISK count all the sectors that that one
file uses.  You will also learn to not trust, or just ignore, TRAPDISK
every time it pops up on your screen.


Ken



Kenneth R. van Wyk                   Calvin: I'm gonna learn to ride this bike
User Services Senior Consultant         if it kills me! ...  AAAAAUUUGGGHHH!!!
Lehigh University Computing Center   Hobbes: Did it kill you?!
Internet: <[e-mail]> Calvin: No, it decided to maim me first.
BITNET:   <LUKEN@LEHIIBM1>
=========================================================================
Date:         Tue, 4 Oct 88 20:37:17 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ed Nilges <EGNILGES@PUCC>
Subject:      Re: 2 years probation
In-Reply-To:  Your message of Sat, 1 Oct 88 20:20:00 EDT

I need information on the Mac nVir virus.  Can anybody help?  All leads
appreciated.
=========================================================================
Date:         Tue, 4 Oct 88 21:05:39 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ed Nilges <EGNILGES@PUCC>
Subject:      nVir help appreciated

Any assistance on the Macintosh nVir virus will be appreciated.
=========================================================================
Date:         Wed, 5 Oct 88 00:22:21 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         me! Jefferson Ogata <OGATA@UMDD>
Subject:      TRAPDISK

I don't think this program is meant to PROTECT you from Trojans and
viruses; I think it's intended for checking out NEW programs you've
just got hold of.  Using it all the time would be silly.  It merely
allows you to find out what sort of disk accesses a suspicious prog-
ram calls for, so you can test it a bit before you let it loose.

- Jeff Ogata
=========================================================================
Date:         Wed, 5 Oct 88 08:15:41 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ken van Wyk <[e-mail]>
Subject:      Re: TRAPDISK
In-Reply-To:  Your message of Wed, 5 Oct 88 00:22:21 EDT

> I don't think this program is meant to PROTECT you from Trojans and
> viruses; I think it's intended for checking out NEW programs you've
> just got hold of.  Using it all the time would be silly.  It merely
> allows you to find out what sort of disk accesses a suspicious prog-
> ram calls for, so you can test it a bit before you let it loose.

That's a good point, if you make a couple of assumptions.  Looking at
a scenario in which some program X is being tested, if X is indeed a
(fill in your favorite malicious program type), and if X either
bypasses INT 13h, or perhaps sees that INT 13h is currently owned by a
program other than the operating system and thus doesn't do its dirty
work until sometime later, then the TRAPDISK program would be useless
and would only give a false sense of safety.  Also, lets say that X is
a game and it uses disk files for keeping track of old scores, for
overlay space, for temporary scratch space, or whatever the reason;
then the TRAPDISK program would give lots of disk read/write warnings
even though X may not be in the least bit malicious.

In short, TRAPDISK may well be an effective program for doing quick
(and dirty) tests on new programs, but the user really should take its
messages (or lack thereof) with a grain of salt, and by no means
consider it conclusive.

Ken



Kenneth R. van Wyk                   Calvin: I'm gonna learn to ride this bike
User Services Senior Consultant         if it kills me! ...  AAAAAUUUGGGHHH!!!
Lehigh University Computing Center   Hobbes: Did it kill you?!
Internet: <[e-mail]> Calvin: No, it decided to maim me first.
BITNET:   <LUKEN@LEHIIBM1>
=========================================================================
Date:         Wed, 5 Oct 88 11:35:17 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe Simpson <JS05STAF@MIAMIU>
Subject:      nVir virus

The listserv at scfvm has a very nice suite of documented Macintosh
anti-viral software, including a comprehensive hypercard documentation
stack.
=========================================================================
Date:         Wed, 5 Oct 88 12:33:12 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Loren K Keim   -- Lehigh University <LKK0@LEHIGH>
Subject:      Conference Outline/Agenda

Because I cannot get mail through to all conference attendies, I
will put it up here.   There is no need to read this if you don't
wish to.


Outline of Conference
---------------------

I  believe everyone has  already  made flight arrangements,  if anyone
needs help, please  contact me  (215)  865-3904.  I  have  sent out  a
number  of  packets to people  attending, some  haven't  gone out yet,
because I'm not sure those people are coming.

For those of you who don't have hotels  yet, directly across  from the
ABE    airport   is  the Sheraton     Jetport  Lehigh  Valley  (Phone:
215-266-1000).  The  conference will not  be too far from the airport,
so this should  be a  good place to  stay.  The prices  here are a bit
higher than  some of   the other hotels  for  those  of  you  on tight
budgets.  Nearby the airport is an Econolodge  (Believe it or not, its
not  a bad hotel!  Phone:  [phone]),  as well as  a Macintosh Inn
(Good for those  of you  who like Apple  Equipment,  I cannot find the
phone number for this,  I'm  still  looking), and the  Red Roof Inn (I
have heard a number of complaints about this hotel, so you may want to
avoid  it.   It  looks  nice from  the  outside,   but rumors pervade.
215-264-5404).

Friday, Oct 21:

     Approxamately half of those coming to the conference will
     be there on Friday.   Introductions will be in order, we
     will hand out copies of the book (although copies will be
     available to those coming Saturday).   We will be holding
     this introduction at one of my offices.  This will be
     held at 701 Main Street in Hellertown (a suburb of Bethlehem).

     Those of you who have gotten directions in the mail have
     gotten a small map of the area, so it will be easier for
     you to find things, but for those of you who might not
     get mail in time:

     Directions from Sheraton Jetport, follow Airport Rd South
     to Rt 22 East.   Take the next exit off 22 onto Rt 378 South.
     Follow Rt 378 to the Hill to Hill Bridge (a large old structure
     where the road narrows, its the ONLY large bridge on the road
     so it is recognizable.).  Bear left off the bridge onto 3rd
     Street of South Bethlehem (Its the old section of town, so
     please excuse its appearance, its undergoing revitalization).
     At any of the first four traffic lights, make a right hand turn
     and a left on the next major road, 4th st.   Follow 4th street
     for about 4 miles, the road will curve to the right twice.
     Eventually, 4th street will become Main Street, Hellertown.
     Our office is a Century 21 Keim Realtors, but its new so I
     doubt we'll have a freestanding sign by the time of the conference.
     The easiest way to recognize the building:  You will see a
     new highway being constructed OVER Main Street; this is the new
     I78 project that's getting so much national attention.  We
     are DIRECTLY across from the furthest exit, at a stoplight
     which has not been turned on yet.  We are between Gutshall
     Chevy and Potts Doggie Shop.

     6:00 PM - 7:00 PM - Introductions with Coffee and Snacks,
     handing out of book.

     7:00 PM - 8:30 PM - What Are Viruses?   What are viruses,
     what forms do they take, including boot sector viruses, .EXE
     viruses, Unix and VMS viruses, and a look at some of the
     new MacIntosh woes.  Reviewing and outlining the ways the
     Lehigh, Brain, Christmas and Israeli viruses worked.  Also
     comparing the Brain and Yale Viruses.

     8:30 PM - 9:00 PM - Questions

     9:00 PM - Morning - Discussion, adjourning to a local bar or
     restraunt to talk.

Saturday, Oct 22:

     Much easier directions, we'll be holding it at WALPS Restaurant
     at the corner of Airport Road and Union Blvd for ease.  Simply
     follow Airport Rd South for about 2 1/2 miles to Union Blvd,
     Walps will be on your left.

     10:00 AM - 11:00 AM - Coffee will be served, "Tracking Computer
     Viruses" will be the topic covering how some groups track computer
     viruses, and some examples.

     11:00 AM - 12:00 Noon - A look at "Computer Tape Worms", their
     uses, how they can cause damage, and why they might be the
     virus of the future.  The damage they can cause.  How we'll have
     to stop damaging ones.

     12:00 PM - 1:00 PM - Break for lunch.  People are welcome to
     stay and eat lunch at Walps, but Union Blvd is a fast food lovers
     paradise, it also contains a major AT&T research facility.
     People can discuss what's been said so far.

     1:00 PM - 2:00 PM - Computer Security Concerns I.  Are schools in
     real danger of losing research?  How can we protect our businesses
     and colleges from the dangers?

     2:00 PM - 3:00 PM - Computer Security Concerns II.   System Integrety
     in large networked environments and mainframes.   Government security
     designs, banking systems and virus defense designs.   Included
     will be Limited Transitivity models, Limited Functionality concerns,
     Bell-LaPadula Model, the Biba Model, Complexity Based Functionality,
     and the Separation Model.  Future concerns will be discussed.

     We're going to break up early, although people are welcome to discuss
     Computers and Security, I feel this lecture will provoke a lot of
     conversation.   You have time to wander and find dinner.


6:00 PM - 9:00 PM - Back in the Hellertown office, we will be holding
     demonstrations.   We will be demonstrating various viruses, including
     a Unix virus, various anti-viral programs and hopefully a Worm program.
     Again Coffee and snacks (baked cookies, brownies and so on) will
     be provided.  We will also at this time be having a panel discussion.
     Questions will be fielded by a panel of anti-virus program writers.


Sunday, Oct. 23:

     10:30 AM - 12:00 Noon - "Future Virus Concerns", closing up the
     lecture on Computer Security, and open forum on ideas and questions.

     12:00 Noon - 1:00 PM - Lunch

     1:00 PM - 4:30 PM - Some controlled discussion, some open forum.
     We'll be discussing possible protection schemes, reviewing some of
     the ideas we've gone over, hopefully working on a new conference
     some time next year in another part of the country, discussing the
     possible dangers to the ATM networks and the dangers to tele-
     communications.

I think the main emphasis of this conference will be a pulling of ideas
and hopefully getting some people to meet and discuss problems face to
face rather than over a computer.

Comments:

University of Texas, I've had problems getting through to you, please
write me at LKK0@LEHIGH or call me at 215-865-3904.

We'll have a price for the book some time in the next few days.

People who haven't so far, please write me and tell me what day you
are coming in.

Dennis Director, please call me.

Also, a number of people mentioned that they would  like directions to
Philadelphia to see the sights and so on.  I'll be making full maps of
the Lehigh Valley Area, Pennsylvania and Philly  available to you when
you get here.   If you are coming  early,  I  will  mail them  to you,
please let me know.  If anyone wants to  spend an hour  and a  half to
trek to New York City, I will try to get you some maps.

Any questions???   Loren Keim

=========================================================================
Date:         Tue, 4 Oct 88 19:16:28 +02
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Ittai Klein Home 471488 Xt. 2363" <MLKLEIN@WEIZMANN>
Subject:      Earnest request

  On behalf of some people that I know and many others, I am sure, that I
do not know, I am voicing this earnest request:

  We are a group that has signed on to this Newsletter out of genuine
concern about the issue at hand, and with real hope of learning about what
could be done to stymie the very serious problem of computer viruses.  But
alas we find ourselves flooded by a torrent of material which is
unnecessarily verbose, much of it simply not related at all to the subject
at hand, often plain smart-alecky, and many times just plain irrelevant.
Examples abound.  I am including here just a short one, which I selected
more or less at random:=========================================================================
Date:         Sun, 9 Oct 88 18:52:56 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "James R. Van Zandt" <[e-mail]>
Subject:      disk-wide CRC program

I have enhanced Ted H.  Emigh's CRC program and posted it at
SIMTEL20.ARMY.MIL.

Here is the blurb...

----------------------------------------------------------------------
PD1:<MSDOS.TROJAN-PRO>FILE-CRC.ARC
      FILECRC calculates CRCs for all files on a disk and records them
      in a file.  COMPARE then compares two such files and reports
      differences, highlighting suspicious changes (file contents
      changed but creation date unchanged).  Useful for spotting viral
      reproduction and/or damage.  This ARC includes source code,
      executables, and documentation for both.  Written by Ted H. Emigh,
      translated from Pascal to C and modestly enhanced by
      James R. Van Zandt <[e-mail]>.
----------------------------------------------------------------------

FILECRC was originally written to detect damage caused by a program run
amok.  I wanted to use it to detect intentional changes, so I have
enhanced it to defeat some of the simpler antiprotection measures a
virus or Trojan horse might attempt.  FILECRC now calculates a CRC on
its own code to detect possible changes, and calculates CRCs starting
at an offset into each file.  The offset is defined at compile time so
it can be different for each installation.  COMPARE reports files
deleted as well as altered.

SIMTEL20 accepts ANONYMOUS ftp logins with any password.

                            - Jim Van Zandt
=========================================================================
Date:         Sun, 9 Oct 88 18:52:56 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "James R. Van Zandt" <[e-mail]>
Subject:      disk-wide CRC program

I have enhanced Ted H.  Emigh's CRC program and posted it at
SIMTEL20.ARMY.MIL.

Here is the blurb...

----------------------------------------------------------------------
PD1:<MSDOS.TROJAN-PRO>FILE-CRC.ARC
      FILECRC calculates CRCs for all files on a disk and records them
      in a file.  COMPARE then compares two such files and reports
      differences, highlighting suspicious changes (file contents
      changed but creation date unchanged).  Useful for spotting viral
      reproduction and/or damage.  This ARC includes source code,
      executables, and documentation for both.  Written by Ted H. Emigh,
      translated from Pascal to C and modestly enhanced by
      James R. Van Zandt <[e-mail]>.
----------------------------------------------------------------------

FILECRC was originally written to detect damage caused by a program run
amok.  I wanted to use it to detect intentional changes, so I have
enhanced it to defeat some of the simpler antiprotection measures a
virus or Trojan horse might attempt.  FILECRC now calculates a CRC on
its own code to detect possible changes, and calculates CRCs starting
at an offset into each file.  The offset is defined at compile time so
it can be different for each installation.  COMPARE reports files
deleted as well as altered.

SIMTEL20 accepts ANONYMOUS ftp logins with any password.

                            - Jim Van Zandt
=========================================================================
Date:         Mon, 10 Oct 88 00:16:00 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         LYPOWY@UNCAMULT
Subject:      The Human End of Computer Viruses

(This may be an area that was beaten to death a while ago, so if this is
the case please speak up!)

Has anyone covered the human end of computer viruses?  In particular,
what motivates a person to write a virus or Trojan Horse?  I realize
that challenge and thrill are immediate motivations, but to what extent
do they apply?  Are they the only thing that keeps 'hackers' going?  I
have an idea that these motivating forces may just be the stepping
stones for an interest, and that once into it, the 'hacker' develops
more sophisticated goals to be met, and for reasons that in the past,
perhaps, didn't occur or matter.  I have yet to see any papers
approaching this topic, which tells me that it is either too obvious to
spend time on, or too broad to cover as a topic on its own (obviously it
would be generalized to cover computer crimes in general, not just virus
writing).

                    Greg.

=========================================================================
Date:         Sat, 8 Oct 88 13:05:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         the Preserver <VISHNU@UFPINE>
Subject:      DCL virus on VMS

Someone asked how the Albany student's virus could have spread without any
specila priveledges. In any large community of users, a number of them will
write their own utilities/programs and share them with other users. An example
here at UF, is the various public access login sequences maintained by
various students for the benefit of the community as a whole. For the
virus to spread rapidly, all that would be necessary would be an infection
of one of these utilities used by many members of the community, then
as the users executed the utility they would infect all of their own files
and presumably any utilities they had written. For anyone familiar with
DCL the program should not pose a problem, in fact the quote of 123 lines
seems inordinately high for such a program.
Possible solutions for VAX managers facing a large community with potential
malcontents include making the default root directory protection no world
read, setting up a dead account to hold utilities submitted by users, and
informing those who do write public utilities to keep the public copy
with the write access disabled.

Les Hill
vishnu@ufpine
[e-mail]
CIRCA consulting, UF
=========================================================================
Date:         Fri, 7 Oct 88 18:42:17 edt
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Bennett Todd <[e-mail]>
Subject:      Re: NY Student caught

>On February 29 a student came to the office of the VMS systems manager
>to announce that "a terrible thing happened:  I was programming a virus
>and it got loose and now it is all over the system."

The article then went on to explain how the student was immediately
restricted, put on probation, and fined 2 grand. That didn't appeal to the
comp center, they got him kicked out. Which makes it clear that (1) it doesn't
matter what your intentions are, only the results, and (2) having slipped up
and let the virus get away, the student shouldn't have reported the problem. I
am sure glad I don't go to that school/work in that comp center/have anything
to do with that crowd. Malicious vengeance breeds in kind. When I was an
undergraduate I and a couple of friends worked many many hours breaking the
security of the departmental minicomputer... with the knowledge of the system
administrator. On those occasions when we managed to crack it we left a note
for the admin somewhere we shouldn't have been able to, and he tried to
figure out (with our help where necessary) a way to plug the revealed security
hole. That was one of the best-run and well-maintained systems I have ever
seen before or since. Now that I am an administrator I would dearly love to
have some users who were that interested and who cared that much about the
system.

-Bennett
[e-mail]
=========================================================================
Date:         Tue, 11 Oct 88 07:22:14 GMT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments:     Warning -- original Sender: tag was [e-mail]
From:         [e-mail]
Subject:      Policy on Informants

I've just read Bennett Todd's msg (Fri 07 Oct 88 18:42) regarding the
handling of the NY student.  My personal opinion is to totally agree.

Several years ago, some teenagers from a local school found a bug in the
HP 2000 BASIC. Some fool(s) thought it was fun to crash the system every
night 10 minutes before shutdown, and we couldn't trace who caused it.

We were grateful when we were told what was believed to cause it, and
once confirmed, HP fixed their bug, happiness returned. No action.

Some staff here don't believe the students really *do* have enquiring
minds and *can* find holes.  Those who believe, tend to have a more open
attitude, and a colleague has "tame" ones checking out particular areas.
They report on their findings, and he watches in case they go off track.

By all means, hit the *real destructive* types, but fine a *well meaning*
informant and you've built a big wall.  Then they do their best to keep
their activities under a smoke screen on their side, and you're on a
losing streak.                 Peter Morgan.

   [ I think my boss agrees with me, but I could be wrong! :-) ]
=========================================================================
Date:         Tue, 11 Oct 88 10:02:48 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe McMahon <XRJDM@SCFVM>
Subject:      Re: Scores??
In-Reply-To:  Scores?? (Mac)


Scores is a highly infective Mac virus supposedly created as a "killer"
of applications with types "ERIC" or "VULT".

It infects applications and system files and spreads very rapidly.

It can be removed either through some fiddly ResEdit hacking or
through the use of KillScores (recommended) or Ferret (not so
recommended).

Both of these are available from LISTSERV at SCFVM.

--- Joe M.
=========================================================================
Date:         Tue, 11 Oct 88 09:56:17 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe McMahon <XRJDM@SCFVM>
Subject:      Re: Sneak virus
In-Reply-To:  Message of Fri,
              7 Oct 88 18:43:00 EDT from
              <portal!cup.portal.com![e-mail]>

I sent private mail about this to some one who asked about it (sorry,
I've forgotten who) ...


SNEAK" detection by Interferon before version 3.1 (now available at
LISTSERV at SCFVM) will detect the LaserWriter and LaserPrep files in
release 6.0 as possibly being infected.


THEY ARE NOT INFECTED !!!!!!

Apple made a change to these files so that they would have new and
different icons. I can explain about all the bizarre things which
the DeskTop file forces you to do when you are changing ICN# resources
if anyone is interested, but it's simply that Apple decided to play
some fun resource games. The new version of Interferon knows about this.

As a note, Interferon is up to version 3.2 (I believe the version being
used by the previous poster was 2.0).


--- Joe M.
=========================================================================
Date:         Tue, 11 Oct 88 12:50:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Brian D. McMahon" <BRIAN@UC780>
Subject:      DCL viri


Commenting on the Albany DCL virus incident, Les Hill writes:

> Possible solutions for VAX managers facing a large community with potential
> malcontents include making the default root directory protection no world
> read, setting up a dead account to hold utilities submitted by users, and
> informing those who do write public utilities to keep the public copy
> with the write access disabled.

May I add to the list of (very sensible) suggestions two more:

BE CAREFUL WHEN YOU EXECUTE A COMMAND PROCEDURE THAT DOES NOT LIVE IN A
TRUSTED ACCOUNT!  (See below)

NEVER, *EVER* EXECUTE A COMMAND PROCEDURE THAT (A) IS NOT IN A SYSTEM
ACCOUNT AND (B) YOU CANNOT READ, ONLY EXECUTE.  Ask yourself what the
author is hiding by setting access to execute-only.

By "trusted", I mean either a system account or one belonging to a
competent, known, and trusted individual; furthermore, as Les points out,
it behooves the system manager to make sure such trusted accounts are
protected against unauthorized modifications.

As was pointed out earlier, yes, DCL procedures *are* essentially plain
text, so protecting yourself against this sort of virus is easy, *IF* you
follow a few simple rules, such as looking at the code before executing it.
The sad thing is, few people do so.  Just remember CHRISTMA EXEC (similar
in that it was a command-procedure sort of thing, only on IBM systems and
propagating over the network) of last year ...


Brian McMahon    <BRIAN@UC780>
=========================================================================
Date:         Tue, 11 Oct 88 13:28:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         the Preserver <VISHNU@UFPINE>
Subject:      Brain virus! HELP!


Hi guys. Guess what? You guessed!

UF has finally contracted a PC virus.

I would like to ask the readers of this list to please send any useful
information on getting rid of and preventing the spread of what is now
called the Pakistani (or (c) Brain) virus. We are particularly interested
in

An original (unmutated) Brain virus either disassembled or on disk.
Any mutated forms of the above mentioned virus, disassembled or on disk.
Any noted behaviors of the Brain virus and its progeny.
Any suggestions on possible remedies.
Any known carriers, eg PKARC

Any and all help is appreciated,

Les
[e-mail]            [e-mail]
[e-mail]       [e-mail]
CIRCA consulting, UF
=========================================================================
Date:         Tue, 11 Oct 88 16:14:29 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Mark F. Haven" <MHQ@NIHCU>
Subject:      Re:  Policy on Informants

The punishment of the Albany student was way out of line - a 2K fine
and booting him out of school for a dumb mistake which he
immediately tried to rectify?  When I was in college a few friends
found a way to lock up a 360 system from APL.  Sure we had a little
fun with a systems manager who got bent out of shape but as quickly
as he cooled down, and a few laughs were shared, the code was
revealed and everyone learned something.  Experimenting is how we
learn and in a youthful university environment safeguards must be
put in place so that "creative computing" won't cause harm to needed
functions.  Proactive security by management will be far more likely
to effectively protect than heavy-handed punishments.  Besides, what
19 or 20 year old really expects themself to get caught no matter
how many severe punishments they might hear of...
=========================================================================
Date:         Tue, 11 Oct 88 16:58:12 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ken van Wyk <[e-mail]>
Subject:      Re: Brain virus! HELP!
In-Reply-To:  Your message of Tue, 11 Oct 88 13:28:00 EDT

> An original (unmutated) Brain virus either disassembled or on disk.
> Any mutated forms of the above mentioned virus, disassembled or on disk.
> Any noted behaviors of the Brain virus and its progeny.
> Any suggestions on possible remedies.

There were some pretty good descriptions (etc.) of the Brain here on
VIRUS-L over the summer (May and/or June, if memory serves me
correctly).  You might want to start by perusing through the archives.

> Any known carriers, eg PKARC

I don't recall hearing anything about PKARC being a carrier of the
Brain virus (which only infects boot sectors).  Unless anyone else has
more info on this, I assume that it's an unfounded rumor.  Please,
lets not turn VIRUS-L into a place to (even accidentally) start
rumors.

Ken



Kenneth R. van Wyk                   Calvin: I can't stop this bike, help!
User Services Senior Consultant      Hobbes: Turn into a gravel driveway and
Lehigh University Computing Center           fall!  Quick!
Internet: <[e-mail]> Calvin: Screeeech!  Boom!  :-(
BITNET:   <LUKEN@LEHIIBM1>           Hobbes: I didn't think you'd listen to me!
=========================================================================
Date:         Tue, 11 Oct 88 15:07:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Shawn V. Hernan" <VALENTIN@PITTVMS>
Subject:      c

Hello,
        Recently here at the University of Pittsburgh we were infected
with the 'nVIR' virus. It was detected with interferon version 3.00 and
is currently being eradicated. It was first noticed on a MAC II w/80 meg
hard disk. It is known to be in at least 3 of the public labs where macs
are available. Also, it has infected some of the evaluation-only machines
available to faculty members. It is assumed that they have carried the
virus back to their machines. Also, we are checking an evaluation library of
about 150 macintosh packages for infection. We are wondering how to inform
the user-community without panic. Any ideas?



                                                Shawn Hernan
                                                Academic Computing
                                                University of Pittsburgh

=========================================================================
Date:         Tue, 11 Oct 88 17:57:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         ACS045@GMUVAX
Subject:      VIRUSCON HELP


Hi,
I'm wondering if somebody out there in netland can give me a hand with
obtaining some more up-to-date info on the VIRUS-CON.
I sent in my registration back in September and haven't heard nary a word
from anybody since August seeing as how we lost our BITNET connection for
most of September and had to sign off VIRUS-L in August since our accounts
were supposed to undergo a name change that never happened.

According to the info I received from a friend before we got cut off from the
net, I was supposed to receive a information packet through the mail detailing
such things as hotel accomodations, a Conference Schedule, exact location of
the Conference, etc. And at this point, 10 days before its supposed to start, I
'm basically one step short of panic with nothing in hand and no answer to any
of the mail I've sent to the coordinators.

If some kind soul could PLEEZ email me any sort of up-to-date info(Like if its
still going on :> ) I would be greatly appreciative.
Thanx,

Steve Okay [e-mail]/[e-mail]/CSR032 on The Source.
=========================================================================
Date:         Tue, 11 Oct 88 12:43:00 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Gordon Meyer <TK0GRM1@NIU>
Subject:      Cursor virus?

Recent reports on a local BBS indicate that there may be a
MS-DOS virus that insists on changing the cursor to a "-"
character at random times throughout a session.  This is
unconfirmed, and so far only one user has reported such a
thing.
I'm in no way "up" on the current MS-DOS virii (owning an
ST myself) so this may be a symptom of an old virus that
I'm just not aware of. Can anybody clarify ?  *IF* this is
a virus, does it appear to be a new strain?
Cheers...
-=->G<-=-
=========================================================================
Date:         Tue, 11 Oct 88 15:16:00 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Bernie <BSWIESER@UNCAMULT>
Subject:      Re: Policy on Informants
In-Reply-To:  Message of 11 Oct 88 14:14 MDT from "Mark F. Haven"

How can anyone defend this student when we don't know what his
intentions were?  I agree, the steps taken were drastic, but if virus
writing is an ethical question then why was he writing one in the first
place?  Curiosity is the first thing that comes to mind.  Now...  If it
is curiosity, then by "hacking" he is learning about something that he
would never be taught in school.  Remember the Cohen experiment.
Instead of delving further into research of viruses the admin.  clamped
down immediately.  Over reaction I say, because of fear.  Fear that in
their high positions they may get their privs.  reduced, not really that
it may GET OUT.  I don't know of any virus which can tell what machine
it is on and reproduce accordingly.  I would imagine if such a thing
were ever written that it would defeat the purpose of virus being small
so they can hide.

Anyhow, Greg, why do people write viruses etc?  Curiosity is one.  Media
hype is two.  Revenge is three.  (Vague as always, BSW)

Ps.  The admin.  at Albany should have hired that student as a security
consultant!  :-) .
=========================================================================
Date:         Tue, 11 Oct 88 16:45:31 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ben Chi <BEC@ALBNYVM1>
Subject:      *NY Student Caught

The last few days have seen some discussion on this list of the "Albany
incident" which occurred at our site.  Not being a VMS heavy myself, I've
asked my VMS Systems Manager to address some of the specific issues
raised by various correspondents.  She writes:

/ --------------------------------------------------------------- First,
/ Bennett Todd ([e-mail]) is very sure our virus contaminator
/ had good intentions because he came to my office to let me know that the
/ virus had "got away".  Detailed examination of the code showed that he
/ was specifically targetting certain usernames (hard coded in) for
/ contamination, and that the main reason he hastened to let me know was
/ that his id and home directory were still hardcoded into the com file
/ which "got away" prematurely, but was always meant to get away.  The
/ system manager for this node would have been -- and remains --
/ interested in a serious security analysis by a serious student.
/ She is not interested in lending credibility to students who write
/ Trojan Horse programs -- in poor DCL at that -- to trip up their
/ unsuspecting friends.
/
/ ----------------------------------------------------------------------
/
/ Now regarding the message from XRAYSROK@SBCCVM:
/
/ 1) Com files are indeed readable ascii files which are coded in DCL
/ (very much like REXX).  As such they are indeed easy to check to see if
/ they contain the lines of code that betray the virus.  That is, ONE com
/ file is easy to check, 4.000 megabytes of files are another matter.  The
/ systems people did run a global search thru the filesystem for the tell
/ tale code. These sanitary measures of course stole cpu and disk from the
/ users.  Part of the payment was to cover such costs.
/
/ 2)  Our "virus" was really a TROJAN HORSE:  many users who were in the
/ habit of using this nasty customer's com files spread the infection to
/ all the files they had WRITE access to (not exe files, the virus just
/ looked for com files, and specifically looked FIRST for the login.com in
/ each user's default directory.)  In fact, as XRAYSROK shrewdly suspects,
/ a bboard (not the one sponsored by the Center, but a student's
/ personal board) was used to spread the virus code.
/
/ 3) Our systems staff are trained to use only code they have checked and
/ tested.  No one with "privs" used the virus com file or the independent
/ board, and so no public files that the Center is responsible for were
/ infected.  No system files were infected.
/
/ 4) About the reason the student came forward, see my reply to previous
/ letter.

What my systems manager does not mention is that all students here are
provided computing access as an entitlement, and in accepting it, agree
not to use it for counterproductive purposes.  Specifically, a student
agrees not to (among other things) not to
  * attempt to interfere with the performance of the system;
  * interfere with the legitimate work of another user;
  * attempt to circumvent system security.
He signs a statement acknowledging that he understands these points and
that nonadherence may result in penalties.

We regard inpenetrable system security as both an unattainable and a
wasteful goal and refuse to use it as a playing field on which to engage
malicious or even curious students.  We simply do not have the resources
to play these games.  We provide students with computer access, BITNET
access, b-boards, and all manner of other amenities.  If they don't wish
to play by our (very reasonable) rules, they can go play somewhere else.
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
Benjamin E. Chi                                      [e-mail]
Director of Technical and Network Services      or [e-mail]
Computing Services Center                     fax available but unlisted
The University at Albany, Albany NY 12222 USA          vox [phone]
=========================================================================
Date:         Tue, 11 Oct 88 18:31:35 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Christian J. Haller" <CJH@CORNELLA>
Subject:      Re: Cursor virus?
In-Reply-To:  Message of Tue, 11 Oct 88 12:43:00 CDT from <TK0GRM1@NIU>

>Recent reports on a local BBS indicate that there may be a
>MS-DOS virus that insists on changing the cursor to a "-"
>character at random times throughout a session.  This is
>unconfirmed, and so far only one user has reported such a
>thing.
>I'm in no way "up" on the current MS-DOS virii (owning an
>ST myself) so this may be a symptom of an old virus that
>I'm just not aware of. Can anybody clarify ?  *IF* this is
>a virus, does it appear to be a new strain?
>Cheers...
>-=->G<-=-
------------------
I doubt that this is the result of a virus attack, but I suppose anything
is possible.  The shape of the cursor is something an application may
change, through documented system calls.  Many applications display the
cursor as a block for insert mode, and an underline for overstrike mode.
Other configurations are possible, even a split cursor with a gap through
the middle.  I recall the cursor being affected sometimes when an
application bombed, especially in BASIC, and once in awhile the system
didn't freeze up right away.  "Normal behavior" for this very unusual
household appliance.
-Chris Haller, Cornell University
=========================================================================
Date:         Tue, 11 Oct 88 19:46:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Damnation,
              all that fuss over two pounds of Earthling brain."
              <PCOEN@DRUNIVAC>
Subject:      RE:  Cursor virus?


I don't know about a virus doing this, but running a CGA program when one's
graphics card is set to monochrome will have the cursor show up like that
A>-.  A program using sloppy procedures could conceivably cause this without
being a virus.
=========================================================================
Date:         Tue, 11 Oct 88 22:23:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Chris Bracy <[e-mail]>
Subject:      RE: Cursor virus?

>Recent reports on a local BBS indicate that there may be a
>MS-DOS virus that insists on changing the cursor to a "-"
>character at random times throughout a session.  This is
>unconfirmed, and so far only one user has reported such a
>thing.

I've worked on a turbo-xt that changes the cursor according to the
speed setting.  Some software can't deal with this and screws up the
cursor up on exit.

Chris.

*==============================*======================================*
|       Chris A. Bracy         |         Student Consultant           |
|       [phone]         |  Lehigh University Computing Center  |
|  [e-mail]  |    Fairchild Martindale Bldg.  8B    |
|   [e-mail]    |           Lehigh University          |
|       [e-mail]     |          Bethlehem, PA 18015         |
*==============================*======================================*
=========================================================================
Date:         Wed, 12 Oct 88 08:50:51 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ken van Wyk <[e-mail]>
Subject:      Re: c
In-Reply-To:  Your message of Tue, 11 Oct 88 15:07:00 EDT

> We are wondering how to inform the user-community without panic. Any ideas?

Assuming that you have a fix for the virus, then you could start by
placing warning messages and signs on any/all of your mainframes
(system bulletins) and in all of your public micro labs.  The signs
should inform the users that there is a virus, what harm (if any) the
virus can do, and how to get rid of it.  Then, make the fix readily
available to all of your users.

That's basically what we did here at Lehigh after some of our student
consultants discovered a virus last Fall.  System bulletins were
issued on all the mainframes, and large, bright signs were placed in
prominent places in all of the microlabs.  A program to remove the
virus was distributed to all of the labs, and made available for
download on all of the mainframes.  Users who were unsure how to
get/run the fix program were told to bring their floppy disks to one
of our sites, where a student consultant would run the fix program for
them, and show them how to run it on their hard drives.  Finally, I
sent a message out on the ADVISE-L forum warning other sites about the
virus, in case it were to spread outside of Lehigh.

Any other ideas or suggestions?

Ken




Kenneth R. van Wyk                   Calvin: I can't stop this bike, help!
User Services Senior Consultant      Hobbes: Turn into a gravel driveway and
Lehigh University Computing Center           fall!  Quick!
Internet: <[e-mail]> Calvin: Screeeech!  Boom!  :-(
BITNET:   <LUKEN@LEHIIBM1>           Hobbes: I didn't think you'd listen to me!
=========================================================================
Date:         Wed, 12 Oct 88 08:26:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         the Preserver <VISHNU@UFPINE>
Subject:      Help with Brain virus wanted

EDU%"[e-mail]"      "Ken van Wyk" writes:
>> An original (unmutated) Brain virus either disassembled or on disk.
>> Any mutated forms of the above mentioned virus, disassembled or on disk.
>> Any noted behaviors of the Brain virus and its progeny.
>> Any suggestions on possible remedies.
>There were some pretty good descriptions (etc.) of the Brain here on
>VIRUS-L over the summer (May and/or June, if memory serves me
>correctly).  You might want to start by perusing through the archives.

I am already doing that. However, we here at CIRCA do not want to spend
time reinventing the wheel while this (supposedly) benign virus sweeps
over campus. In order to minimize the damage done, we would greatly appreciate
anyone sharing their previous work with us.

>I don't recall hearing anything about PKARC being a carrier of the
>Brain virus (which only infects boot sectors).  Unless anyone else has
>more info on this, I assume that it's an unfounded rumor.  Please,
>lets not turn VIRUS-L into a place to (even accidentally) start
>rumors.
>Ken

What I meant to say is this. The virus spread to us from a local BBS which
had an arced file which when unarced released the initial Trojan that
set the Brain up. Anyone else heard of this? Or are we the victims of a
local virus hacker? (not suprising)

Les Hill
[e-mail]            [e-mail]
[e-mail]       [e-mail]
CIRCA consulting, UF
=========================================================================
Date:         Wed, 12 Oct 88 09:59:54 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe McMahon <XRJDM@SCFVM>
Subject:      Announce w/o Panic

Since the nVIR virus is a Mac virus, I suggest you also provide
Vaccine to the persons involved and make up a big poster showing
the Vaccine dialog with a message reading "HAVE YOU SEEN THIS
DIALOG?" along with what to do, who to see, and assurances that it
is (relatively) easy to fix.

--- Joe M.
=========================================================================
Date:         Wed, 12 Oct 88 10:10:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Shawn V. Hernan" <VALENTIN@PITTVMS>

Hello,
        Just yesterday we discovered 'nVIR' here, and now we have something
I've never heard of. Does this look familiar to anyone:
We used Virus Rx to check a program for the nVIR virus and found this:

_________________________
Invisible files and INITs embedded in system files
@#$% FILE----Bostb Be Evill--------:
________________________________________

Warning: Files are too new. *
ZSYS MACS--------System----------:
________________________________________
SUMMARRY: Invisible Files & Questionable INITs: 1
*One or more questionable files were found.   *
*These don't seem to be of immediate concern. *
*You may wish to check their resource forks.  *
*Relax for now but run this program again later.  *



The file 'Bostb Be Evill' has us somewhat concerned.  Anyone know what this
might be?

                                                        Shawn Hernan
                                                        Valentin@pittvms
                                                        University of Pittsburg
=========================================================================
Date:         Wed, 12 Oct 88 10:43:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Mann muss immer alles umkehren <PGOETZ@LOYVAX>
Subject:      nVir?

So what's the nVIR virus?
=========================================================================
Date:         Wed, 12 Oct 88 10:59:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Hugh Pritchard/Catholic U of America Computer Ctr <PRITCHARD@CUA>
Subject:      Re: NY student

Bernie <BSWIESER@UNCAMULT> writes, jocularly,

> Ps.  The admin.  at Albany should have hired that student as a security
> consultant!  :-) .

People who stumble upon holes in security, or who malevolently take
advantage of other users' naivete, gullibility, or trust HAVE BY NO
MEANS displayed any qualifications as any sort of "security consultant".

/Hugh Pritchard,             |on BITNET:    PRITCHARD@CUA
Senior Systems Programmer    |on INTERNET:  [e-mail]
                             |     or       [e-mail]

The Catholic University of America Computer Center  [phone]
Washington, DC 20064, USA

Disclaimer:  My views aren't necessarily those of the Pope.
=========================================================================
Date:         Wed, 12 Oct 88 11:56:26 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe Simpson <JS05STAF@MIAMIU>
Subject:      Macintosh viruses and countermeasures

There is an excellent article on the common macintosh viruses, including
detailed descriptions of how they work, can be identified, and can be
eradicated.  The article also attempts to put the virus issue into
appropriate perspective and , in my opinion, succeedes. As a
bonus social and legal issues are covered.  My congratulations to a
remarkable author!

MacWorld, November 1988, "Mad Macs", Suzanne Stefanac, ppg 93-101.
=========================================================================
Date:         Wed, 12 Oct 88 13:14:06 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         me! Jefferson Ogata <OGATA@UMDD>
Subject:      Bost be Evill

About 2 months ago there was an outbreak of this sort elsewhere. I don't
recall where, but it's in the VIRUS-L archives. Which brings me to
a question:

How do you grab VIRUS-L archives?

- Jeff Ogata
=========================================================================
Date:         Wed, 12 Oct 88 11:23:27 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Re: Brain virus! HELP!
In-Reply-To:  Message from "the Preserver" of Oct 11, 88 at 1:28 pm

>
>
>Hi guys. Guess what? You guessed!
>
>UF has finally contracted a PC virus.
>
>I would like to ask the readers of this list to please send any useful
>

Ok I give up. Who or what is UF?  We must all be aware that this is a
global board, and that not all of us are on the same campus, or even
in the same country.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

=========================================================================
Date:         Wed, 12 Oct 88 13:18:12 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ed Nilges <EGNILGES@PUCC>
Subject:      Re: NY student
In-Reply-To:  Message of Wed, 12 Oct 88 10:59:00 EDT from <PRITCHARD@CUA>

>Bernie <BSWIESER@UNCAMULT> writes, jocularly,
>
>> Ps.  The admin.  at Albany should have hired that student as a security
>> consultant!  :-) .
>
>People who stumble upon holes in security, or who malevolently take
>advantage of other users' naivete, gullibility, or trust HAVE BY NO
>MEANS displayed any qualifications as any sort of "security consultant".
>


I heartily agree, yet in spite of Mr. Chi's recent posting on this
brouhaha, I still believe that the student's punishment was cruel
and unusual.  Mr. Chi revealed that the student's primary concern
seemed to be that his own directory was threatened by the virus.
However, the student doubtless knew that if he revealed his behavior
to the systems manager, he would probably lose the account anyway.
The wording of his confession "something terrible has happened"
reveals, to this writer, an honest remorse and desire to fix the
problem.

No, the student should NOT be hired as a security consultant.  But
neither is it ethical or fair to make him a nonperson.  Community
service, and a course in business and scientific ethics, seem to
be the ticket here.  It still appears that the student's case appeared
at exactly the wrong time, right after a TIME magazine article which,
although reasonably accurate and well-researched, spread fear among
non-programming computer users as to the safety of their files.  The
case also sets a bad precedent, for real programmers will be at risk
if ethics and law do not discriminate between honest mistakes, negligence,
and malice.  Imagine losing your job over a bug...who said it, in
Shakespeare's King Lear, "use every man according to his deserts,
and who should 'scape whipping?"?


Disclaimer: these views are mine, and do not represent those of
my employer.
=========================================================================
Date:         Wed, 12 Oct 88 14:04:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         the Preserver <VISHNU@UFPINE>
Subject:      Brain virus help....

I thought everyone knew, UF is the University of Florida :->

Les  [e-mail]
=========================================================================
Date:         Wed, 12 Oct 88 14:17:58 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ken van Wyk <[e-mail]>
Subject:      Re: Bost be Evill
In-Reply-To:  Your message of Wed, 12 Oct 88 13:14:06 EDT

> How do you grab VIRUS-L archives?

As described in my monthly announcement, you can get the archives by
sending mail to LISTSERV@LEHIIBM1.  Please do *not* send this to
VIRUS-L@LEHIIBM1!  In the message, put any of the following commands:

HELP            - gives you some info on using the LISTSERV.
INDEX VIRUS-L        - lists the files available on the LISTSERV.
GET filename filetype    - sends the requested file to you via e-mail.

The archive files are in the following format:

VIRUS-L LOGyymmw

where yy is the year (88), mm is the month (05, 06, ...), and w is the
week (A, B,...).  For example, VIRUS-L LOG8809A contains the first
week's worth of conversations in September, 1988.  Note that there's a
space between the filename and filetype, not a period like in most
operating systems.

Ken




Kenneth R. van Wyk                   Calvin: I can't stop this bike, help!
User Services Senior Consultant      Hobbes: Turn into a gravel driveway and
Lehigh University Computing Center           fall!  Quick!
Internet: <[e-mail]> Calvin: Screeeech!  Boom!  :-(
BITNET:   <LUKEN@LEHIIBM1>           Hobbes: I didn't think you'd listen to me!
=========================================================================
Date:         Wed, 12 Oct 88 14:42:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         ACS045@GMUVAX
Subject:      Thanx and one more question...

Thanx to all of you who sent me the Conference info....now if you'll indulge
me one more question...how close is the Allentown Holiday Inn to all of this??
I couldn't afford the Sheraton and wasn't willing to take a chance on any of
the local hostelries so thats where I'
                                      m going to be
Also, if there's anybody else from Virginia going drop me a mail message...my
ride just pulled out from going and so I'm trying to work out alternate
transportation,etc.
(I'll be there on Friday...I've put too much aggravation into this to give up
 now :>)

---Steve
=========================================================================
Date:         Wed, 12 Oct 88 13:28:00 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ken  De Cruyenaere   204-474-8340 <KDC@UOFMCC>
Subject:      Global Board

   >Ok I give up. Who or what is UF?  We must all be aware that this is a
   >global board, and that not all of us are on the same campus, or even
   >in the same country.

Good point!  While we"re at it, who or what is UTEP ??

Ken De Cruyenaere   Computer Security Coordinator
University of Manitoba - Winnipeg, Manitoba, Canada
=========================================================================
Date:         Wed, 12 Oct 88 15:34:41 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Mark F. Haven" <MHQ@NIHCU>
Subject:      Re:  Global Board

>Date:         Wed, 12 Oct 88 13:28:00 CDT
>From:         Ken  De Cruyenaere   204-474-8340 <KDC@UOFMCC>
>Subject:      Global Board
>
>>Ok I give up. Who or what is UF?  We must all be aware that this is a
>>global board, and that not all of us are on the same campus, or even
>>in the same country.
>
>Good point!  While we"re at it, who or what is UTEP ??

UTEP is a BITNET address for the University of Texas at El Paso
     Computer Center.
UF   is a common abbreviation for the University of Florida.

Given that this is a very international board it would be helpful
if we avoid abbreviations, no matter how common we think they
are.
=========================================================================
Date:         Wed, 12 Oct 88 16:21:44 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David M. Chess" <CHESS@YKTVMV>
Subject:      The "Brain" virus from an ARC file

That's very interesting!   I've never heard of anyone getting it
that way before.   Are you sure that's what happened?   There is
an ARC file going around the boards that contains a binary dump
of the "Brain", but you'd have to take rather sophisticated
conscious action to produce an infected diskette from it.  If
there's really an executable (EXE or COM or...) going around that
puts the "Brain" onto a diskette, I think we'd all like to
hear about it.  Please go on!

Dave Chess
Watson Research
=========================================================================
Date:         Wed, 12 Oct 88 16:46:00 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         GREENY <MISS026@ECNCDC>
Subject:      re: re: NY Student

>> P.S. The admin.  at Albany should have hired that student as a security
>> Consultant :-).
> People who stumble upon holes in security, or who malevolently take
> advantage of other users' naivete, gullibility, or trust HAVE BY NO
> MEANS displayed any qualifications as any sort of "security consultant".
> /Hugh Prichard

Personally, I think that they would ahve been much better off to simply
put the student on Disciplinary Probation, and then given him a job in
the computing center as a consultant.  That is probably what the student
was looking for in the first place, and by his own admission that he wrote
a virus which escaped -- he proved that he does have some responsible bones
in his body.  If he didnt, then he could have simply claimed that a rogue
hacker got into his account, and proliferated a viral program to get him
into trouble -- and no one would have probably been able to prove a thing.

Several years ago, I was introduced to the UNIX system here at my campus
and quickly grew to love it -- the brevity of the commands made it a dream
for someone like me who despises "user friendly" interfaces who assume that
you really dont want to do something that you went to the trouble to key in..
UNIX doesn't bug ya with annoying messages.  Also, it is very secure if
set up in the proper manner....however, several years ago, I accidently
discovered a bug one day when I performed a shell escape from MAIL and created
a temporary message to send to a collegue....the file I created was owned
by ROOT (not my account...) and from this it was relatively easy to obtain
superuser status on the machine.  I went to the system admin. and informed
him of this bug.  We quickly became friends as he saw that I was a responsible
individual, and he made the offer to me that "if I ever wanted superuser
status for *ANY* reason, that he would give it to me...", but that
he would appreciate it "if I were to ask for it, and not simply take it,
because if someone got into my account, then it could create havoc...".  This
request was simple, and I have lived with it for a long time.  We are still
friends, and when I come across a bug or a sec. hole, I tell him.  But if I
had been fined $2K, suspended, and whatever else, then you can bet that the
university would be having some severe problems with getting me to stop
spreading information about all of the bugs.....first ammendment rights
would probably protect me enough so that I could produce a "For Informational
Purposes Only" newsletter about the computing bugs....and as we all are
well aware of -- accounts are VERY easy to come by.

----
Moral of this dialogue?:  Simple really, when you find a hacker -- befriend
him/her/it and try to use it to *YOUR* advantage.  Besides, if the hacker
could program well enough to get in, why not hire the hacker...the hacker
has proven his/her/its capabilities already, and to not utilize them to
the fullest would be foolish...

....*flame off* -- mellow out and give the guy a second chance...
Bye for now but not for long
Greeny
Bitnet: miss026@ecncdc
Internet: [e-mail]
Disclaimer: #include<std_legal_mumbo_jumbo.h>

P.s. I definately know what school I'm *NOT* going to continue my graduate
     studies at... :->
=========================================================================
Date:         Wed, 12 Oct 88 16:04:09 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Jim Marks <JMARKS@GTRI01>
Subject:      Re: Global Board
In-Reply-To:  Message of Wed, 12 Oct 88 13:28:00 CDT from <KDC@UOFMCC>

In reply to question about UTEP...

How did that come up?

Anyway, UTEP stands for University of Texas at El Paso (I guess that's
what you mean).  This is as opposed to the University of Texas at Austin,
or UT for short, which is also short for University of Tennessee (at Knoxville)
.  Which is probably why what Ken said makes a lot of sense.  After all, here
in the Southeast, USC often means Univ. of South Carolina, while in California
it means something else.

We're quite often overassuming (is that a word?) on here.  If in the slightest
doubt (and this doesn't just go for college names), spell it out.


Jim Marks
Georgia Tech Research Institute (GTRI)
Georgia Institute of Technology (GIT or GT...)
=========================================================================
Date:         Wed, 12 Oct 88 14:43:52 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Douglas James Martin <USERDJMA@UALTAMTS>
Subject:      Re: NY student

> The wording of his confession "something terrible has happened"
> reveals, to this writer, an honest remorse and desire to fix the
> problem.

Maybe I misunderstood the previous postings, but it sounded to me like the
virus 'got away' while evidence of the author remained in it. On that basis
my immediate suspicion would be that the author knew he would be caught and
hoped that by coming forward he might reduce the unavoidable consequences.

It doesn't sound to me like there was any "honest mistake" involved; he
WAS working on a Trojan Horse (at least, according to these postings), which
just happened to go off before he planned it to.

I don't have the information to say whether I'd be in favour of indefinite
suspension, since there isn't enough detail given about what the Trojan
Horse did to its "recipients", but I'd almost certainly be in favour of
cutting off the guy's computing access.



=========================================================================
Date:         Wed, 12 Oct 88 17:22:00 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         LYPOWY@UNCAMULT
Subject:      Conference Attendance


Is there anyone else out there from Canada planning Is there anyone else
(on this list) from Canada who is planning on attending the upcoming
virus conference?

(Send me E-Mail...don't reply to this message or the list will be full
of mail that not everyone needs to wade through :-) ).

          Greg Lypowy (LYPOWY.UNCAMULT.BITNET)

P.S.  I'm just curious really!
=========================================================================
Date:         Wed, 12 Oct 88 22:06:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Shawn V. Hernan" <VALENTIN@PITTVMS>
Subject:      networks

Does anyone know for sure whether the 'nVir' virus can spread over a
network? Specifically appleshare and TOPS? That is, if I'm running
an application from a file server, is the floppy in my machine at risk.
I suspect yes, but some MacIntosh folx I know think otherwise. (they are
not familiar with viruses at all). Any help is appreciated.

                                        Shawn V. Hernan
                                        Valentin@pittvms
                                        University of Pittsburgh
=========================================================================
Date:         Thu, 13 Oct 88 08:59:46 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe McMahon <XRJDM@SCFVM>
Subject:      Re: networks
In-Reply-To:  Message of Wed, 12 Oct 88 22:06:00 EDT from <VALENTIN@PITTVMS>

None of the Mac viruses now known can actively transfer across a network.
If you run a program on a server which is infected, that program can
infect your machine. However, if your machine is infected, it cannot
infect the server. The program MUST be run on the target system to
infect it. Clear? :-)

---Joe M.
=========================================================================
Date:         Thu, 13 Oct 88 09:29:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Glen Matthews <CCGM@MCGILLM>
In-Reply-To:  In reply to your message of WED 12 OCT 1988 13:28:00 EDT

The University of Texas at El Paso, 'natch!
=========================================================================
Date:         Thu, 13 Oct 88 08:37:00 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Gordon Keegan <C145GMK@UTARLG>
Subject:      Ditto

> P.s. I definately know what school I'm *NOT* going to continue my graduate
>  studies at... :->

That goes for me, too!
=========================================================================
Date:         Thu, 13 Oct 88 13:51:13 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Neil Goldman <NG44SPEL@MIAMIU>
Subject:      Wang/VS Virus

No, I am not currently aware of any wang/vs viruses, however I am interested
to know if anyone has seen or heard of any.

Thanks.

Neil A. Goldman                        [e-mail]

Replies, Concerns, Disagreements, and Flames expected.
Mastercard, Visa, and American Express not accepted.
=========================================================================
Date:         Thu, 13 Oct 88 16:04:01 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe McMahon <XRJDM@SCFVM>
Subject:      (Mac) Networks and Virus Spread

Gene Lott <GENEL@UNMB> has pointed out to me how a file server could
infect a number of other machines. He is absolutely correct - an infected
server will allow you to infect your machine if you run any of its software
on yours. Also, if a user with write access to the server is infected, the
server can become infected.

The AppleTalk networks I was thinking of were in general simpler ones, without
file sharing or servers - a typical two-Macs-and-a-LaserWriter setup. In this
case, the known viruses will not spread from machine to machine, because
they are unable to use AppleTalk themselves to propagate - they must be
carried by driver (vector? :-) ) software.

--- Joe M.
=========================================================================
Date:         Thu, 13 Oct 88 17:46:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         The CAEC managers <CAEC@VUVAXCOM>
Subject:      Help!

To Everyone:

        Help!  My name is Tom Kurke, and I am a consulant at Villanova
University... apparantly we have been infected by some kind of "virus"
"trojan-horse" or something....
        Let me give you the information that I know now.  Apparently,
when using Bank Street Righter, (in our micro-labs, using floppy disks
with hard disk access... dos is on the hard disk), Bank Street Righter
corrupts the information on the data disk- namely, all of the files
are still on the disk (they haven't been written over), but there
are no directory enteries for them.  Stranger than that, if you use Norton
to peek at the FAT sectors and the DIR sectors, you find that in almost
all cases a file has been saved in the DIR area, either in sector 12 or
sector 14, areas reserved specifically for directory information.
        Also, when trying to call the files up using Bank Street Righter,
an "@" appears in the upper right hand corner, or a date like 6/11/88.
Any information that you can provide me about this would be greatly appreciated.

        I am not one who knows much about Bank Street Righter- nor how it
saves files, but does this sound like a viral attack or just a hacker
doing something to corrupt our copies of Bank Street Righter?

        Any information that you can provide me with will be greatly
appreciated... thank you!

                                   Sincerely,

       +               +            *  Tom Kurke
       |               |      V     *  Consultant
      | |      +      | |     I U   *  Computer Aided Engineering Center (CAEC)
      | |      |      | |     L N   *  College of Engineering
     |   |    / \    |   |    L I   *  Villanova University
     |   |    | |    |   |    A V   *  Villanova PA, 19085
     |   |   /   \   |   |    N E   *
    I-----I /     \ I-----I   O R   *  NuclearTHREATNet:  Villanova.Bomb
    |     |/       \|     |   V S   *  Bitnet: CAEC@VUVAXCOM
    |     |---------|     |   A I   *  UUCP: ...!vu-vlsi!excalibur!CAEC
    |     |         |     |     T   *  MA-BellNet: [phone]
    |     |         |     |     Y   *  Home of the Wildcats!
    |     |         |     |         *
    |     |         |     |         *  A standard disclaimer applies to anything
    -----------------------         *  that I may have blabbed about above-- the
                                    *  views I have expressed are soley mine,
UNIVERSITY COMPUTING                *  not the University's... come to think of
           AND                      *  it,if that EVER happened that would be a
        INFORMATION SERVICES        *  strange coincidence indeed!!!  ;-)

=========================================================================
Date:         Thu, 13 Oct 88 16:43:29 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Kevin Trojanowski <[e-mail]>
Subject:      RE: NY Student


I agree that the punishment in this case WAS a bit severe.

But, by the same token, to give the student a job as a consultant, or
security person would do nothing but encourage this kind of activity.  Anyone
wanting a job in such a position would have to do nothing but hack their
way into the system somehow, and create a virus, or trojan horse.  Far
from productive, I think.

-Kevin Trojanowski
 [e-mail]
=========================================================================
Date:         Thu, 13 Oct 88 18:22:09 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         GARY SAMEK <C133GES@UTARLVM1>
Subject:      RE: NY Student
In-Reply-To:  Message of Thu,
              13 Oct 88 16:43:29 CDT from <[e-mail]>

I would like to share a similiar situation, as far as hiring a student
who is known to have done questionable activities on a computer.
Back when we had a dec 2060, a high school student discovered that he
could advise the operator console from a batch file, an obvious security
problem.  He then used the operator privs to discover the passwords for
all of the priveleged accounts.  We decided that the best move was to reset
all of the passwords for all of the accounts which became a very uncomfortable
situation on the entire campus.  We were finally able to catch this individual
the second time he tried the same trick.  Our user services manager had a talk
with this individual and felt that this person could be trusted since he was
only experimenting with a main frame.  This manager hired the student when
he began to attend classes at this university.  The student was hired on as
a user assistant, a student worker who is available outside the hours of
8-5 for students unfamiliar with the use of computers.  With this job he given
an account with few resource restrictions, but no privs (at least some
intelligence had been shown up to this point).  When the student was promoted
a year later to problem analyst, which is essentially a first defense for
staff members, he gained access to an account with limited privs.  The student
then used these privs to begin to learn how to bypass accounting records of his
activities.  The first time he caught doing this, this institution gave him a
verbal slap on the hands, yet continued to show their good will and trust by
letting the situtation end at that.  The student was again caught doing the
activities as before when he had unsuccessfully attempted to update his
accounting records on all three of the main frames we had at the time.
Finally, the student was brought before a university review board and
suspended for one year from this university.

In summation, it has been my experience that once someone is let off too
easily from a major offense, that this individual will be unable to find
a reason to discontinue his activities.  He will only feel that it is more
exiting, and that he only needs to be a little more careful next time.
Thus, a feeble attempt in discipline may only lead to a potentially
greater risk in the future.

I apologize for the long letter, but this is a very embarassing situation for
the university and those of us who maintain the computers for the academic
environment.

Disclaimer: These views are entirely from my own viewpoint and no one else's.
            At the time of these activites, I was in no way responsible for
            hiring and firing, nor I was I responsible for the security or
            maintainance of these mainframes.

Gary Samek
  Bitnet  C133GES@UTARLVM1
  Telnet  C133GES@UTARLG
  Arpanet [e-mail]
=========================================================================
Date:         Thu, 13 Oct 88 19:10:52 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Re: networks
In-Reply-To:  Message from "Joe McMahon" of Oct 13, 88 at 8:59 am

>
>None of the Mac viruses now known can actively transfer across a network.
>If you run a program on a server which is infected, that program can
>infect your machine. However, if your machine is infected, it cannot
>infect the server. The program MUST be run on the target system to
>infect it. Clear? :-)
>

That seems strange to me.  It seems that in any system, if a file is
writable, then a virus can write to it.  Of course, if read-only
status can be enforced, then infection of the file can be prevented.

Thus, only if a server file is read-only, and NO code in the local
machine can write to the server, is the obove true.

Any comments?

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
=========================================================================
Date:         Thu, 13 Oct 88 21:12:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Daniel M. Greenberg" <DMG4449@RITVAX>
Subject:      RE: NY Student

Gary Samek (C133GES@UTARLVM1) writes:

    > In summation, it has been my experience that once someone is let off too
    > easily from a major offense, that this individual will be unable to find
    > a reason to discontinue his activities.  He will only feel that it is more
    > exiting, and that he only needs to be a little more careful next time.
    > Thus, a feeble attempt in discipline may only lead to a potentially
    > greater risk in the future.

    That is quite a strong generalization.  Your experience with just one
    person has condemned all.  This might even be correct in a majority
    of cases, but not always.  Some people do learn from their mistakes.
    Oh, and by the way, I think the fault when when the University didn't
    do anything to make him realize it was serious the first time he
    tampered with the accounting.  Just in case you don't know, many
    past hackers work for large corporations or the government as informants
    on with security

    Daniel
=========================================================================
Date:         Thu, 13 Oct 88 21:04:03 PDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         portal!cup.portal.com![e-mail]
Subject:      Bank Street Righter

Are you sure that's not Bank Street Writer?  Anyway, it sounds to me like a
perfectly ordinary bug in the program.  Contact the author or get another copy
of the program from a completely different source (like the author) and see
if the two programs are the same size and behave the same way.  Do a DIFF on
the two programs.

If they are identical and both corrupt data, it is most likely a bug.
If they are different, than one of three things has happened:  you have a
buggy file, a file which was corrupted during transmission by line noise
or a file which has been deliberately modified to be hostile.

The last of those is the least likely, and the first the most likely.  Most
programs that trash data have bugs.


Dan Hankins
=========================================================================
Date:         Fri, 14 Oct 88 07:07:46 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Otto Stolz [phone] <RZOTTO@DKNKURZ1>
Subject:      How can we help, at all?  OR: netiquette, again

To Tom Kurke:
   What sort of system are you using?  McIntosh??  Unix???  MS-DOS????
   Atari????? Other??????

To everybody on this list:
   Please, please, please, DO INDICATE THE SYSTEM in question in the
   subject fields of you contributions.  Let's know, what you are gonna
   discuss with us!  After all these dicussions, I still do not know,
   to which sort of systems the "Pakistani" and "Brain" viri are bound
   -- honestly!  Can anybody tell me?

To Ken:
   Same holds for VIRUS-L FILELIST, available from LISTSERV at LEHIIBM1.
   The NOBRAIN, FluShot+, and other programs are USELESS to everybody
   who doesn't know (like me) for which system they are ment -- and I
   reckon that is the major part of possible users of this service.

I hope that helps (me and everybody in this discussion group :-)

Otto
=========================================================================
Date:         Fri, 14 Oct 88 10:09:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David M. Chess" <CHESS@YKTVMV>
Subject:      Ex-hackers (was "Re: NY Student")

Daniel M. Greenberg (DMG4449@RITVAX) mentions in passing:
>  Just in case you don't know, many past hackers work for large
>  corporations or the government as informants on with security

Does anyone have any evidence (there I go again!) that this is
really true?   It's certainly "common knowledge", and it happens
constantly in paperback novels, but the few actual security managers
that I've mentioned the subject to have generally laughed at the
idea, and indicated that an ex-cracker would be the *last*
person they'd want to hire.

DC
=========================================================================
Date:         Fri, 14 Oct 88 10:45:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         EAE114@URIMVS
Subject:      Hackers as security consultants

On the idea that hackers can and. or should be
hired as security consultants:

In the not-so-old days when competent computer people
were hard to come by, It made sense to hire hackers
to help your security effort.  The extra effort to
control them and the leap of faith required were made
worthwhile, because of the limited pool of talent
available.   I do not think this is true anymore.

It IS still true that hackers may be an important
source of talent, IF you have the resources to control
them, or a loose enough situation to prevent severe dammage.
If, as in most places I've been, you can't spare the
effort, I'd still say that a first offence ought to result
in forced restitution and a real short chain.  Class this as
stupidity, rather than malice.   A second offence is evidence
of both stupidity AND severe mental defectiveness,
and ought to get a body bounced as high as you can
get them.
                     Eristic (EAE114@URIMVS)
=========================================================================
Date:         Fri, 14 Oct 88 11:05:43 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe Simpson <JS05STAF@MIAMIU>
Subject:      Macintosh network exposure to viruses

The generally imprecise use of terminology in network discussion may
mislead persons discussing the potential for spread of viruses on
Macintosh networks.

"Appletalk" is a generic name for a suite of protocols defined by Apple
Computer.  The suite of protocols, in and of themselves, provides very
little applications level service.  Useful applications are built on top
of the Appletalk protocols.  For example, Laser printing service and
network dot matrix printing.  To share data one must add additional
software.  Two very common products to accomplish this are AppleShare and
TOPS.  Using these as our models we can talk about network exposure to
viral contamination.

First.  If a virus is written to use low level appletalk protocols directly
to spread a virus from an infected host, I believe that the target machine
would have to be running software beyond the low level protocol suite.  Some
examples would be disk sharing software or email software.  We are now talking
about a very sophisticated (and probably very large virus).  Note that the
requirement of higher level software is a premise and not an established fact.

Second.  A virus that interacts with disk media at the read/write block
level probably cannot propagte via read/write block over the network.
Again this is a premise not a verified conclusion.

If one accepts these premises, network exposure to viruses falls into two
classes.

Class B (banal).  If one is running disk or file sharing software and executes
a virus vector on the local machine, then the local machine is at the same
level of risk that it assumes if the executable application were resident.
This statement also applies to trojans and generally buggy software and is
a tribute to clean design and accurate coding of the Macintosh OS and Appletalk
protocol suite.

Class A (awful).  The typical virus assumes a domain of addressable files
(volumes only if one accepts low level read/write which I do not).  If an
infected host has in its domain of addressible files, a subset that is
addressable by other, uninfected, clients of the network, then the network
should accelerate the spread of the virus.  My premise, not verified
conclusion, is that many disk/file sharing applications on Appletalk are
very clean implementations and present a "local disk" image to applications
that avoid low level read/write.

Tentative conclusions.
The risk is real and must be assessed against the benefits of the network.
Network administrators (and under tops individual clients) should develop
a strategy to determine the scope of files that are addressable by others
and the permisions granted to these persons.

Obvious(?) techniques to reduce exposure.
1.  Don't permit access to a system folder by other than the local machine.
2.  Where practical, make executable applications read only.
3.  Try to limit write access to shared domains to data files only.

If any one is able to confirm or invalidate any of my premises, I would be
very grateful to them.
=========================================================================
Date:         Fri, 14 Oct 88 11:17:59 PDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      Re: Ex-hackers (was "Re: NY Student")
In-Reply-To:  Your message of Fri,
              14 Oct 88 10:09:00 -0400. <[e-mail]>

Lawrence Livermore National Labs employs one ex-cracker in computer security.

An article about him was published in the Oakland Tribune (10/11/88).

                            -Peter Yee
                            [e-mail]
                            ames!yee
=========================================================================
Date:         Fri, 14 Oct 88 14:23:23 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         SHERK@UMDD
Subject:      Re: networks
In-Reply-To:  Message received on Thu, 13 Oct 88  20:24:40 EDT

=========================================================================

>
>>None of the Mac viruses now known can actively transfer across a network
>>If you run a program on a server which is infected, that program can
>>infect your machine. However, if your machine is infected, it cannot
>>infect the server. The program MUST be run on the target system to
>>infect it. Clear? :-)
>

>That seems strange to me.  It seems that in any system, if a file is
>writable, then a virus can write to it.  Of course, if read-only
>status can be enforced, then infection of the file can be prevented.

>Thus, only if a server file is read-only, and NO code in the local
>machine can write to the server, is the obove true.
Any comments?
| Leonard P. Levine               e-mail [e-mail] |

There is an important differance between network drives and local
drives. To use DOS as an example, when a program wants to write to
a file it calls INT 21 with subfunction 40h (Write to file or device).
DOS will then determine what type of device the file is on. If the
device is a network drive, DOS will hand off the request to the network
software. But if the device is a local disk, DOS will call INT 26h
(Absolute disk write) to write the data to disk.
     The (c) Brain virus called INT 26h directly, so it can't infect
a network drive. This is the blessing/curse of machine dependent code!

Erik Sherk
Workstation Programer, Computer Science Center.
University of Maryland
=========================================================================
Date:         Fri, 14 Oct 88 15:48:44 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Mark F. Haven" <MHQ@NIHCU>
Subject:      Move discussion on virus writers

I suggest we move discussion on rewards and/or penalties and/or
excommunication for virus writers to a more appropriate list
ETHICS-L and reserve this list for matters of a more technical
nature.

ETHICS-L is moderated by Harry Williams (HARRY@MARIST) and is
described as being to : "delineate and discuss the basic issues and
hot areas in computer ethics.  Topics include ownership of
information, who is responsible for program failures, how much
privacy is reasonable.  Students are welcome to participate."  The
preceding was plagiarized in toto without permission from a listing
on my desk from whence I know not where it came.
=========================================================================
Date:         Fri, 14 Oct 88 14:04:00 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Bernie <BSWIESER@UNCAMULT>
Subject:      Re: Hackers as security consultants
In-Reply-To:  Message of 14 Oct 88 08:45 MDT from "EAE114 at URIMVS"

I don't get it.  How can showing an intrest in things imply malice.
Unfortunately I still believe people are not inately evil.  If computer
science has this Calvinistic attitude for long, we'll never see
innovation or advance again.
=========================================================================
Date:         Fri, 14 Oct 88 15:37:29 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Re: networks
In-Reply-To:  Message from "[e-mail]" of Oct 14, 88 at 2:23 pm

>>Thus, only if a server file is read-only, and NO code in the local
>>machine can write to the server, is the obove true.
>Any comments?
>
>There is an important differance between network drives and local
>drives. To use DOS as an example, when a program wants to write to
>a file it calls INT 21 with subfunction 40h (Write to file or device).
>DOS will then determine what type of device the file is on. If the
>device is a network drive, DOS will hand off the request to the network
>software. But if the device is a local disk, DOS will call INT 26h
>(Absolute disk write) to write the data to disk.
>     The (c) Brain virus called INT 26h directly, so it can't infect
>a network drive. This is the blessing/curse of machine dependent code!
>
>Erik Sherk
>
Interesting, however the virus can call the same routines that the DOS
server does.  Thus, only if the server file is read-only AT THAT END
can you be sure that a virus cannot infect the server.  If code at the
user end can write to the server, in any way, then a virus code can do
the same.  Read-only files, protected at the server end where the
virus is assumed not to reside, are protected.

(as an aside, we have moved the discussion from MAC to DOS here, we
also are discussing what a virus can do, not what known viruses
actually do.  I for one am discussing potential and not existing
threats.)

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
=========================================================================
Date:         Fri, 14 Oct 88 16:55:00 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Gordon Meyer <TK0GRM1@NIU>
Subject:      employing ex-hackers

To answer DC's question about ex-hackers working for large
corporations or the government.  Yes, I have evidence and
can confirm that statement for you.  However, the ones that
I am aware of work as informants, not as "regular" employees.
They continue to be active in the hacker's world, but they in
turn supply information to the gov't or large corporations.

On other matters it has been interesting to read the various
"harsh punisments result in halted activity" arguments.  This
too seems to be a popular notion but is on shaky theoretical and
empirical grounds.  But then I'm a criminology graduate student
so I guess I'm "into" such things.  :-)

Cheers!
-=->G<-=-=========================================================================
Date:         Sat, 15 Oct 88 16:20:00 GMT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Danny Schwendener <SEKRETARIAT@CZHETH5A>
Subject:      Re: Networks

>>None of the Mac viruses now known can actively transfer across a network.
>That seems strange to me.  It seems that in any system, if a file is
>writable, then a virus can write to it.  Of course, if read-only
>status can be enforced, then infection of the file can be prevented.

We're speaking about the *currently known* mac viruses. Theyinfect
either system files on the boot-up disk or/and applications when
these are invoked. No doubt that you can write a virus that detects
all volumes on line and infects part or all of the applications on
these volumes (as long as they're not write-protected), but apparently
no one has done this yet (knock on wood).

-- Danny

+-----------------------------------------------------------------------+
| Mail   :   Danny Schwendener, ETH Macintosh Support Center            |
|            Swiss Federal Institute of Technology, CH-8092 Zuerich     |
| Bitnet :   macman@czheth5a      UUCP   :   {cernvax,mcvax}ethz!macman |
| Ean    :   [e-mail]   Voice  :   yodel three times          |
+-----------------------------------------------------------------------+
=========================================================================
Date:         Fri, 14 Oct 88 23:42:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         ACS045@GMUVAX
Subject:      Penalties for Hackers

>If, as in most places I've been, you can't spare the
>effort, I'd still say that a first offence ought to result
>in forced restitution and a real short chain.  Class this as
>stupidity, rather than malice.   A second offence is evidence
>of both stupidity AND severe mental defectiveness,
>and ought to get a body bounced as high as you can
>get them.
>                     Eristic (EAE114@URIMVS)


sounds like most places you've been are a lot more lenient than our place
 over here....
We just had a nasty bit of business where a student consultant either wrote
a VMS trojan .COM file or showed a user how to write a .COM file, which was
then sent around the system and managed to zap a few accounts before the
file was discovered.

No short chain for him.....he was fired faster than a speeding bullet..
It turned out that he didn't really DO anything in terms of writing or
distributing the beast, but just the mere fact that his name came up a
few times in the resulting inquisition was enough to get him canned...

=========================================================================
Date:         Sun, 16 Oct 88 15:51:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Peter D. Junger" <JUNGER@CWRU>
Subject:      Isn't "hacker" an honorific?

        I find it troublesome--and perhaps even a subject that has
ethical implifications--that in the current discussion about the
student who wrote a virus that got away, the term "hacker" is used
as if it were some sort of label applied to a class of criminals, like
the label "burglar".  As I understood the original use of the term,
it described those who make computers do what they they want the
silly machines to do, as opposed to "loosers" who can only do what
the machine (and its administrators and programmers) lets them do.
Admittedly some HACKERS want to do undesirable things with their
machines, but others write EMACS.  Considering the fact that
the virus in question was written in some sort of job control language
and that it blew up in its author's face--he sounds more like a looser
than a hacker.  Users often want to do undesirable things to0.

        The use of the word "hacker" on this list thus seems to me
a rather unpleasent example of group defamation.  I suspect
that part of the dislike for hackers that is expressed within
the computer community is based, not on the fact that some hacks are
nasty, but on the fact that hackers are free, i.e., out of control,
i.e., out of the control of those who don't like people to be free.

        On the other hand, perhaps there is no ethical issue at all.
Perhaps the word "hacker" has come to be a pejorative because
words change their meanings over time, and that is all there is to
it.  After all, I my old highschool geometry teacher worked during
the summer as a computer.  Words do change.

Peter Junger              JUNGER@CWRU
=========================================================================
Date:         Fri, 14 Oct 88 18:54:00 PDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ed Sakabu <CSMSETS@UCLAMVS>
Subject:      Re: Hackers as security consultants


The term "Hacker" now days has a totally different meaning than it did
in the not-so-old days. The term I prefer to use for these turkeys is
"cracker" not "Hacker". Well, there's my two cents. Thanks for not
flaming me.

            --Ed

> On the idea that hackers can and. or should be
> hired as security consultants:
>
> In the not-so-old days when competent computer people
> were hard to come by, It made sense to hire hackers
> to help your security effort.  The extra effort to
> control them and the leap of faith required were made
> worthwhile, because of the limited pool of talent
> available.   I do not think this is true anymore.
>
> It IS still true that hackers may be an important
> source of talent, IF you have the resources to control
> them, or a loose enough situation to prevent severe dammage.
> If, as in most places I've been, you can't spare the
> effort, I'd still say that a first offence ought to result
> in forced restitution and a real short chain.  Class this as
> stupidity, rather than malice.   A second offence is evidence
> of both stupidity AND severe mental defectiveness,
> and ought to get a body bounced as high as you can
> get them.
>                      Eristic (EAE114@URIMVS)

=========================================================================
Date:         Sun, 16 Oct 88 10:41:24 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         SHERK@UMDD
Subject:      Re: networks
In-Reply-To:  Message received on Fri, 14 Oct 88  18:49:33 EDT


>>     The (c) Brain virus called INT 26h directly, so it can't infect
>>a network drive. This is the blessing/curse of machine dependent code!
>>
>>Erik Sherk
>>
>Interesting, however the virus can call the same routines that the DOS
>server does.  Thus, only if the server file is read-only AT THAT END
>can you be sure that a virus cannot infect the server.  If code at the
>user end can write to the server, in any way, then a virus code can do
>the same.  Read-only files, protected at the server end where the
>virus is assumed not to reside, are protected.
>
>(as an aside, we have moved the discussion from MAC to DOS here, we
>also are discussing what a virus can do, not what known viruses
>actually do.  I for one am discussing potential and not existing
>threats.)

Your point is well taken. Here at U of Maryland we are very concerned
with network server security. That is why we are trying to implement
an NFS server to serve all of the three types of microcomputers in
our public workstation rooms. A Network File System offers Unix
style security for our users programs and data ( i.e. a user can run
a program from a execute only disk and still have read/write access
to his data files on the server).
     It seems to me, that you are against any write access to a server
because of the potential for a virus to infect public programs.:-) Do

you think that, because of a *potential* threat, we should limit the
functionality of our servers?

Erik Sherk
Workstation Programmer, Computer Science Center
University of Maryland

=========================================================================
Date:         Sat, 15 Oct 88 02:06:30 +0200
Reply-To:     gany@taurus
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments:     If you have trouble reaching this host as MATH.Tau.Ac.IL Please
              use the old address: [e-mail]
From:         GANY@TAURUS
Subject:      Re : Ex hackers

I think we are getting carried away with this argument about employing
ex-hackers so i will try to make this short.
1. I have a friend who used to hack around with our university's
   giant CDC CYBER a few years ago when we were both in high-school.
   We had access to the computer as we were doing a form of "graduation
   paper" for school.
   That person was caught messing around with resources he had no access to
   (like accounts he used to "borrow"). He was reported to school and was
   punished in the form of "not to lay foot on the computer building as
   long as he in college".
   This person is working up to this date as consultant on the same
   computer site (and believe me, he is good at what he is doing (advising
   on languages and operating system). Just don't say they (the computer
   operators) have short memory - they knew exactly who they were hiring.
2. I  remember myself trying to hack around with the same computer
   ("with a little help from my friends") not always doing honest things.
   Today i am working next door as member of the system staff on a UNIX system
   on the same university and also have privileged access to that CDC.

So, to the main point - the reason some of hackers do "bad" things is
because they are bounded and they like the game of trying to loosen the
tights. (i hope my English is right)
Give them enough space (i.e privileges) and suddenly they stop hacking
and start acting like "grownups" and do useful things.
Now don't get me wrong - IN NO WAY YOU SHOULD ENCOURAGE HACKING !!.
But when it comes to hiring a person to a job requiring "privileged access",
the fact he used to be a hacker should NOT misqualify him automaticaly !
Don't judge a book by it's cover.
I'm sure most system administrators have enough brains to smell
a trouble maker in few days - before he is given enough privileges.

Sorry for the length of this posting - it makes me furious to hear opinions
like "once a hacker always a hacker" as if hacker means thief.
I'm sure many of you reading this posting used to be hackers too,
so let's concentrate in more important things like how to prevent
unwanted penetrations to systems (which ofcourse includes trojan-horses).

thanks for listening.

Yair Gany
Tel Aviv University - School of Mathematics and Computer Science.

=========================================================================
Date:         Sun, 16 Oct 88 23:29:21 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Prof Arthur I. Larky" <AIL0@LEHIGH>
Subject:      I am proud to be a hacker!

I've been a 'hacker' for 32 years.  I wrote programs for Lehigh
computers to do things I thought needed doing even though no one asked
for them.
  I don't attack other people's computers because I don't want people
attacking mine.  (Fred Cohen attacked one of mine and I dumped him off
of it immediately.)
  Sometimes I attack one of my own computers, but usually by accident.
  Lets find some other term for the malicious ones and keep 'hacker'
for the guy who likes to see what useful things he can do with a
computer.
  I wonder how you get someone to pay a $2300 fine without going to
court?  Also, would he have paid if he knew he was going to be thrown
out of school?  The fact that the school could re-consider and up the
penalties proves that universities are not bound by such minor
legalities as double jeopardy.
  Art
=========================================================================
Date:         Sun, 16 Oct 88 23:58:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      RE: I am proud to be a hacker!

>  Lets find some other term for the malicious ones and keep 'hacker'
>for the guy who likes to see what useful things he can do with a
>computer.

Oftentimes, a student who has a reputation for being a "hacker,"
or experienced computer user, might be charged with computer mischief
merely for being labelled as such, even though s/he might not be the
type of person who would ever do anything maliciously.

David  - "It could happen to me.  It could happen to you."


=========================================================================
Date:         Mon, 17 Oct 88 00:34:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Dimitri Vulis <DLV@CUNYVMS1>

Please... stop using the word 'hacker' if you don't know what it means...

Users who maliciously destroy data, plant viruses, Trojan horses, etc are
usually too dumb/ignorant to qualify as hackers. I had XMAS EXEC sent to
my CMS account last winter, and I took the usual precaution of _looking_ at
it before running it.  It was _immediately_ obvious to be what it was
supposed to do (i.e. display a XMAS tree and send copies of itself to all
the folks in my NAMES file), so I did not run it, and I sent a stern
warning to the person who sent it to me; however, it was written in such an
amaterurish matter that it really made me puke.

It is my understanding that _most_ viri, Trojans, etc are written by
children under 18 are primitive and full of bugs that render them less
harmful than meant by their authors.

A 'hacker' is, generally speaking, an anthusiastic systems programmer---
nothing less, nothing more. The media (flame=on) sometimes misuse this
term to describe what really are phreaks and/or crackers. Well, one may
follow this usage, and one may use the term 'virus' generically instead of
'Trojan horse' or 'time bomb' etc, and one will sound like one does not
know what one is talking about, which is probably the case. (flame=off).

Programming expertise and a malicious destruction of other people's data
seldom coincide.

Now, about employing 'hackers' (crackers) in computer centers: I think it's
a real bad idea. A person caught snooping around other people's data (even
w/o destroying anything) cannot be trusted with the power inherent in
(almost) any systems support job. Even a lowly student consultant is
in position to notice passwords being typed, for example. In the past (I mean
real dark past, 10--15 years ago) there were so few knowledgeable users
available that (school) DP people had to hire such folks as consultants etc
because they picked up something about the system while snooping which they
could pass on to othet users. Well, today the systems are (somewhat) easier
to use, and the pool of knowledgeable users is much wider, so the cracker
types can and should be blacklisted.

Users caught trying to destroy other users' data or to interfere with the
operation of the computer center ought to be punished in the most severe
manner available. Some years ago I had some of my files erased by a sicko
who was working for the computer center (a realy psychopath). I was not
too happy about it, obviously.

I think SUNY@Albany was completely right in kicking the butt of the loser
who tried to launch a virus and could not do even that competently. It's
too bad they could not put him to jail as well. They should also publicize
the incident as widely as possible. Hopefully, this will make others like
the student in question think twice before attempting to write something
like this. Being lenient with system abusers generated a wrong kind of message
--- that systen abuse is tolerated at this particular installation.

-Dimitri Vulis
-CUNY GC, Math department
=========================================================================
Date:         Sun, 16 Oct 88 13:47:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      Re: Policy on Informants
In-Reply-To:  Message of 11 Oct 88 16:14 EDT from "Mark F. Haven"


>The punishment of the Albany student was way out of line - a 2K fine
>and booting him out of school for a dumb mistake which he
>immediately tried to rectify?

It is difficult for me to assess the appropriateness of the punishment.
I have no difficulty at all with the $2380.   As I understand the
original submission, this was restitution, not a fine.  It is well
settled in common law that anyone who plays with dangerous things is
liable to others for any damage that he causes.

As to probation, as recommended by the Student Committee on Conduct, and
expulsion, as granted by the authorities on appeal from the system
administrators, it seems to me that there is some data missing.  I would
like to know what rules, besides the obvious social ones against playing
with dangerous substances in crowded places, were violated.  Under what
explicit rules or agreements did the student use the system?  What
sanctions were provided in those rules or agreements?  If the punishment
was imposed "ex post facto," then I have some little sympathy.  However,
if the student knowingly put himself in danger of a published sanction,
then I have none at all.

Participation in an academic environment carries with it certain
responsibilites.  These include the responsibility not to "blot
another's copy book," use his work without proper attribution, and not
to tamper with his experiments.  Because it is often difficult to
understand how these rules apply in a computer environment, I think that
it behooves a self-interested academic community to put its members on
explicit notice.  In order to enforce their interest, such a community
must be prepared to shun, ostracize, and expel those who violate the
notices.  While I can sympathize with one who unintentionality offends
in the absence of such explicit notice, I do not necessarily believe
that the failure to give notice about every possible kind of offense
compromises the right of the community to invoke sanctions for offenses
that fall under the broad definitions of unacceptable behavior.

____________________________________________________________________
William Hugh Murray                     216-861-5000
Fellow,                                 203-966-4769
Information System Security             203-964-7348 (CELLULAR)
Ernst & Whinney                         ARPA: WHMurray @ DOCKMASTER
2000 National City Center               MCI-Mail: 315-8580
Cleveland, Ohio 44114                   TELEX: 6503158580
                                        FAX: [phone]
21 Locust Avenue, Suite 2D              Compu-Serve: 75126,1722
New Canaan, Connecticut 06840           TELEMAIL: WH.MURRAY/EWINET.USA

=========================================================================
Date:         Mon, 17 Oct 88 07:34:38 GMT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments:     Warning -- original Sender: tag was [e-mail]
From:         [e-mail]
Subject:      Terminology problems  &  Vote call

Dimitri Vulis <[e-mail]1>   (17 Oct 88 00:34:00 EST)  writes...
> Please... stop using the word 'hacker' if you don't know what it means..

In the UK, a minority of people would know of the term "cracker".  A
book (third issue came out this year) called "The Hacker's Handbook", on
the subject of connecting to other people's systems and logging in, only
makes it more confusing.  I saw a list of many terms used in the USA of
which (fortunately) few have alternative meanings in the UK.  Outside
the specialist terms from MIT etc, onto mundane things...  a (US) bus is
a (UK) coach [eg Greyhound], and a (Can) pavement is a (UK) road. I was
*very* confused by that until I found a (Can) sidewalk is a (UK) pavement.
"Get on the pavement" could be dangerous!    Suggestions anyone?


> Now, about employing 'hackers' (crackers) in computer centers:
> I think it's a real bad idea.

Can anyone suggest a means by which we can take a vote?  (Must be able
to receive votes by MAIL not just SEND (n/a worldwide)).  I'm not sure
[having commented on 'Informants'] that CONTINUING a 50:50 (??) matter
is of value on any list...      Must say I found all views of value.

           Peter Morgan, Computer Centre, Brighton Poly.
[e-mail]   or   [e-mail]

[ Decision please, from On High  --  Ken... LUKEN@LEHIIBM1 ]
=========================================================================
Date:         Mon, 17 Oct 88 09:17:41 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ken van Wyk <[e-mail]>
Subject:      Re: Terminology problems & Vote call
In-Reply-To:  Your message of Mon, 17 Oct 88 07:34:38 GMT

> Can anyone suggest a means by which we can take a vote?  (Must be able
> to receive votes by MAIL not just SEND (n/a worldwide)).  I'm not sure
> [having commented on 'Informants'] that CONTINUING a 50:50 (??) matter
> is of value on any list...      Must say I found all views of value.

A couple of related things...  First, the arguments (both for and
against) about hiring "hackers" have gone on for quite some time now
with both sides making very interesting points.  I suggest that they
be continued on the ETHICS-L list, as suggested by a reader, however.
The same goes for the arguments about the definition/history of the
term "hacker"; interesting as it is, it doesn't really have much of a
place here.  Both things can be argued ad infinitum with neither side
claiming a decisive victory.

Thanks in advance for everyone's cooperation on this matter.

Ken



Kenneth R. van Wyk                   Calvin: I can't stop this bike, help!
User Services Senior Consultant      Hobbes: Turn into a gravel driveway and
Lehigh University Computing Center           fall!  Quick!
Internet: <[e-mail]> Calvin: Screeeech!  Boom!  :-(
BITNET:   <LUKEN@LEHIIBM1>           Hobbes: I didn't think you'd listen to me!
=========================================================================
Date:         Mon, 17 Oct 88 09:24:16 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Mark F. Haven" <MHQ@NIHCU>
Subject:      First, let's kill the teachers.

>Date:         Fri, 14 Oct 88 23:42:00 EST
>From:         ACS045@GMUVAX
>Subject:      Penalties for Hackers
>
>sounds like most places you've been are a lot more lenient than our place
> over here....
>We just had a nasty bit of business where a student consultant either wrote
>a VMS trojan .COM file or showed a user how to write a .COM file, which was
>then sent around the system and managed to zap a few accounts before the
>file was discovered.
>
>No short chain for him.....he was fired faster than a speeding bullet..
>It turned out that he didn't really DO anything in terms of writing or
>distributing the beast, but just the mere fact that his name came up a
>few times in the resulting inquisition was enough to get him canned...

Please tell us there's more to this than what you said, in
particular "he didn't really do anything but just the mere fact that
his name came up a few times".  On that basis you would be firing
your top and most accessible instructors who provide information in
the most understandable way.  I've taught hundreds of people how to
write in various languages.  Some of them I've spent a lot of time
helping.  Are you saying that if one of them wrote a destrustive
program and then told you I taught him a language, and several
others said I often answered such questions, then I'd be out like a
speeding bullet?  (In such a case I guarantee my lawyer would beat
up your lawyer.)
=========================================================================
Date:         Mon, 17 Oct 88 10:58:02 edt
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         GATEH@CONNCOLL
Subject:      SET VIRUS-L REPRO

SET VIRUS-L REPRO
=========================================================================
Date:         Mon, 17 Oct 88 11:27:06 edt
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         GATEH@CONNCOLL
Subject:      a vote

=========================================================================
Date:         Mon, 17 Oct 88 09:06:00 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      hackers

Just a comment...weren't the original founders of APPLE Computers considered to
be hackers?  This isn't a flame but a commentary.  One can learn a lot by
poking around programs etc., perhaps a lot more than in school.  Like every-
thing else there are "good" ones and "bad" ones
Allen Gordon
Univ Colorado
=========================================================================
Date:         Mon, 17 Oct 88 11:30:44 edt
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         GATEH@CONNCOLL
Subject:      another attempt at voting

I vote to move the hacker/hire-fire/definition-genealogy discussions to
another list (perhaps ETHICS-L, as other folks have mentioned), and
reserve this list for more technical topics.

that'll be two cents


Gregg TeHennepe                        | BITNET:  gateh@conncoll
Minicomputer Specialist                | Phone:   [phone]
Academic Computing and User Services
Connecticut College
New London, CT

=========================================================================
Date:         Mon, 17 Oct 88 10:18:44 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Re: networks
In-Reply-To:  Message from "[e-mail]" of Oct 16, 88 at 10:41 am

>> Read-only files, protected at the server end where the
>>virus is assumed not to reside, are protected.
>>
>     It seems to me, that you are against any write access to a server
>because of the potential for a virus to infect public programs.:-) Do
>
>you think that, because of a *potential* threat, we should limit the
>functionality of our servers?
>
>Erik Sherk

I have no desire to limit systems, I am interested only in becoming
aware (and in helping others to become aware) of the threat and what
we will have to do to protect against it.

Thus far it seems to me that:

No conventional MS-DOS or MAC stand alone installation that accepts
executable files from another system is safe.  (The basic failure is
that there is no forbidden code area that any user program cannot
penetrate in either of these designes.  Thus, anything that the virus
writer wants to do, s/he can do.)

No system (whatever its form) that permits a user to write executable
code for another user to execute is safe if the later executer
(pardon the english) is a system level user or has serious files to
protect.

The best safety is in the form of a lock with a known form but an
unknown key.  (There is no way to permanently hide the form of the
lock.  The design of the Yale lock is known to many.  The shape of the
key however, can be hidden from the perp ((as we say in Hill Street))
and can be changed at will.)

Finally, I know of no existing virii that do the nasty things that the
above imply.  I know that some will come though.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
=========================================================================
Date:         Mon, 17 Oct 88 13:08:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Tom O'Toole - HCF <ECF_STBO@JHUVMS>
Subject:      Please stop this drivel!

This same arguement (hackers... degenerating into "what is a hacker" etc...)
reared it's ugly head on info-vax a while ago and took forever to die. The
moderator of this list has requested that the discussion be moved to another
list, yet the messages are still coming. And PLEASE drop the notion of a "vote"
immediately. Let's get on with it, 'cuz we're wasting our time. Thanks...


Tom O'Toole
JHUVMS system programmer
Homewood Computing Facilities
Johns Hopkins University
Balto. Md. 21218
[e-mail]



=========================================================================
Date:         Mon, 17 Oct 88 13:59:40 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David M. Chess" <CHESS@YKTVMV>
Subject:      networks

Len Levine lists some problems that allow viruses to propogate:

> ...there is no forbidden code area that any user program cannot
> penetrate...

>                               ...permits a user to write executable
> code for another user to execute ... if the later executer
> (pardon the english) is a system level user or has serious files to
> protect.

I would suggest that the first of these things is not at all
necessary for a virus to spread and to do damage, and that the
second of these things is a necessary feature of any real system
at all (there are no systems where no one executes any code
that was written by someone else, and every serious user has
at least one serious file).

Because of these thoughts, I would object (again) to any suggestion
that MS-DOS and MAC systems are more vulnerable to viruses
than are any other systems.  How about changing the sentence
in question to read:

> No conventional computer installation that accepts
> executable files from another system is safe.

Forgive me if I harp on this, but I'm constantly reading and
hearing how it's just these silly micros that are vulnerable to
viruses, and that as soon as they get to be more like mainframes,
we'll be safe.   It's not true...

On the otherhand, I agree wholeheartedly that known-form locks
with unknown keys are a very promising approach to all this.

DC
=========================================================================
Date:         Mon, 17 Oct 88 15:18:22 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Christian J. Haller" <CJH@CORNELLA>
Subject:      Re: Conference Outline/Agenda
In-Reply-To:  Message of Wed, 5 Oct 88 12:33:12 EDT from <LKK0@LEHIGH>

>Because I cannot get mail through to all conference attendies, I
>will put it up here.   There is no need to read this if you don't
>wish to.
>
>
>Outline of Conference
>---------------------
>
>I  believe everyone has  already  made flight arrangements,  if anyone
>needs help, please  contact me  (215)  865-3904.  I  have  sent out  a
>number  of  packets to people  attending, some  haven't  gone out yet,
>because I'm not sure those people are coming.
>
>For those of you who don't have hotels  yet, directly across  from the
>ABE    airport   is  the Sheraton     Jetport  Lehigh  Valley  (Phone:
>215-266-1000).  The  conference will not  be too far from the airport,
>so this should  be a  good place to  stay.  The prices  here are a bit
>higher than  some of   the other hotels  for  those  of  you  on tight
>budgets.  Nearby the airport is an Econolodge  (Believe it or not, its
>not  a bad hotel!  Phone:  [phone]),  as well as  a Macintosh Inn
>(Good for those  of you  who like Apple  Equipment,  I cannot find the
>phone number for this,  I'm  still  looking), and the  Red Roof Inn (I
>have heard a number of complaints about this hotel, so you may want to
>avoid  it.   It  looks  nice from  the  outside,   but rumors pervade.
>215-264-5404).
>
>Friday, Oct 21:
>
>     Approxamately half of those coming to the conference will
>     be there on Friday.   Introductions will be in order, we
>     will hand out copies of the book (although copies will be
>     available to those coming Saturday).   We will be holding
>     this introduction at one of my offices.  This will be
>     held at 701 Main Street in Hellertown (a suburb of Bethlehem).
>
>     Those of you who have gotten directions in the mail have
>     gotten a small map of the area, so it will be easier for
>     you to find things, but for those of you who might not
>     get mail in time:
>
>     Directions from Sheraton Jetport, follow Airport Rd South
>     to Rt 22 East.   Take the next exit off 22 onto Rt 378 South.
>     Follow Rt 378 to the Hill to Hill Bridge (a large old structure
>     where the road narrows, its the ONLY large bridge on the road
>     so it is recognizable.).  Bear left off the bridge onto 3rd
>     Street of South Bethlehem (Its the old section of town, so
>     please excuse its appearance, its undergoing revitalization).
>     At any of the first four traffic lights, make a right hand turn
>     and a left on the next major road, 4th st.   Follow 4th street
>     for about 4 miles, the road will curve to the right twice.
>     Eventually, 4th street will become Main Street, Hellertown.
>     Our office is a Century 21 Keim Realtors, but its new so I
>     doubt we'll have a freestanding sign by the time of the conference.
>     The easiest way to recognize the building:  You will see a
>     new highway being constructed OVER Main Street; this is the new
>     I78 project that's getting so much national attention.  We
>     are DIRECTLY across from the furthest exit, at a stoplight
>     which has not been turned on yet.  We are between Gutshall
>     Chevy and Potts Doggie Shop.
>
>     6:00 PM - 7:00 PM - Introductions with Coffee and Snacks,
>     handing out of book.
>
>     7:00 PM - 8:30 PM - What Are Viruses?   What are viruses,
>     what forms do they take, including boot sector viruses, .EXE
>     viruses, Unix and VMS viruses, and a look at some of the
>     new MacIntosh woes.  Reviewing and outlining the ways the
>     Lehigh, Brain, Christmas and Israeli viruses worked.  Also
>     comparing the Brain and Yale Viruses.
>
>     8:30 PM - 9:00 PM - Questions
>
>     9:00 PM - Morning - Discussion, adjourning to a local bar or
>     restraunt to talk.
>
>Saturday, Oct 22:
>
>     Much easier directions, we'll be holding it at WALPS Restaurant
>     at the corner of Airport Road and Union Blvd for ease.  Simply
>     follow Airport Rd South for about 2 1/2 miles to Union Blvd,
>     Walps will be on your left.
>
>     10:00 AM - 11:00 AM - Coffee will be served, "Tracking Computer
>     Viruses" will be the topic covering how some groups track computer
>     viruses, and some examples.
>
>     11:00 AM - 12:00 Noon - A look at "Computer Tape Worms", their
>     uses, how they can cause damage, and why they might be the
>     virus of the future.  The damage they can cause.  How we'll have
>     to stop damaging ones.
>
>     12:00 PM - 1:00 PM - Break for lunch.  People are welcome to
>     stay and eat lunch at Walps, but Union Blvd is a fast food lovers
>     paradise, it also contains a major AT&T research facility.
>     People can discuss what's been said so far.
>
>     1:00 PM - 2:00 PM - Computer Security Concerns I.  Are schools in
>     real danger of losing research?  How can we protect our businesses
>     and colleges from the dangers?
>
>     2:00 PM - 3:00 PM - Computer Security Concerns II.   System Integrety
>     in large networked environments and mainframes.   Government security
>     designs, banking systems and virus defense designs.   Included
>     will be Limited Transitivity models, Limited Functionality concerns,
>     Bell-LaPadula Model, the Biba Model, Complexity Based Functionality,
>     and the Separation Model.  Future concerns will be discussed.
>
>     We're going to break up early, although people are welcome to discuss
>     Computers and Security, I feel this lecture will provoke a lot of
>     conversation.   You have time to wander and find dinner.
>
>
>6:00 PM - 9:00 PM - Back in the Hellertown office, we will be holding
>     demonstrations.   We will be demonstrating various viruses, including
>     a Unix virus, various anti-viral programs and hopefully a Worm program.
>     Again Coffee and snacks (baked cookies, brownies and so on) will
>     be provided.  We will also at this time be having a panel discussion.
>     Questions will be fielded by a panel of anti-virus program writers.
>
>
>Sunday, Oct. 23:
>
>     10:30 AM - 12:00 Noon - "Future Virus Concerns", closing up the
>     lecture on Computer Security, and open forum on ideas and questions.
>
>     12:00 Noon - 1:00 PM - Lunch
>
>     1:00 PM - 4:30 PM - Some controlled discussion, some open forum.
>     We'll be discussing possible protection schemes, reviewing some of
>     the ideas we've gone over, hopefully working on a new conference
>     some time next year in another part of the country, discussing the
>     possible dangers to the ATM networks and the dangers to tele-
>     communications.
>
>I think the main emphasis of this conference will be a pulling of ideas
>and hopefully getting some people to meet and discuss problems face to
>face rather than over a computer.
>
>Comments:
>
>University of Texas, I've had problems getting through to you, please
>write me at LKK0@LEHIGH or call me at 215-865-3904.
>
>We'll have a price for the book some time in the next few days.
>
>People who haven't so far, please write me and tell me what day you
>are coming in.
>
>Dennis Director, please call me.
>
>Also, a number of people mentioned that they would  like directions to
>Philadelphia to see the sights and so on.  I'll be making full maps of
>the Lehigh Valley Area, Pennsylvania and Philly  available to you when
>you get here.   If you are coming  early,  I  will  mail them  to you,
>please let me know.  If anyone wants to  spend an hour  and a  half to
>trek to New York City, I will try to get you some maps.
>
>Any questions???   Loren Keim
>
=========================================================================
Date:         Mon, 17 Oct 88 16:13:07 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         MICHAEL LEE <CM10@WUBLUE>
Subject:      Re: Re: networks



Someone mentioned the Yale lock.  Can you explain more?  It sounds
interesting but I have no idea of what it entails.

                                                   Mike Lee
                                                   WASH Univerisity
                                                   ST. LOUIS, MO

=========================================================================
Date:         Mon, 17 Oct 88 13:53:48 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Mark F. Haven" <MHQ@NIHCU>
Subject:      Another vote.

I support Gregg TeHennepe's urge that we move this to ETHICS-L.  Two
reasons, first the traffic is voluminous and has to be sorted
through by those interested in the more technical aspects of
viruses, second ETHICS-L has been completely silent for months and
is defined as the forum for just this kind of discussion, second and
a half - this is getting boring but I feel the need to stay sub_
scribed to VIRUS-L for the technical stuff and the discussion on who
is a "hacker", did the Albany student get too much or too little,
etc.  has gotten beaten to death (and boredom) already.
                              Mark F. Haven
                              Computer Specialist
                              National Institutes of Health
                              Bethesda, MD
=========================================================================
Date:         Mon, 17 Oct 88 11:33:00 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Grep the Peg <BSWIESER@UNCAMULT>
Subject:      Re: I am proud to be a hacker!
In-Reply-To:  Message of 16 Oct 88 22:58 MDT from "ZDABADE at
              VAX1.CC.LEHIGH.EDU

Right on.  I lost my account on the University of Calgary vaxes four
times in my first year.  Once because I used "rlogin" when I wasn't
supposed to.  Three other times because of unfounded "rumour".  It seems
the sysops fastest way to get me into his office was to turn off my
account.  I don't even think what I did classifies as hacking...
=========================================================================
Date:         Tue, 18 Oct 88 14:30:00 CET
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Helmut Waelder <ZRWA001@DTUZDV1>
Subject:      re:

> From:         GATEH@CONNCOLL
> Subject:      another attempt at voting
>
> I vote to move the hacker/hire-fire/definition-genealogy discussions to
> another list (perhaps ETHICS-L, as other folks have mentioned), and
> reserve this list for more technical topics.
>
> that'll be two cents
>
>
> Gregg TeHennepe                        | BITNET:  gateh@conncoll

I agree with Gregg.
This here should be a virus discussion list ....
Helmut Waelder
=========================================================================
Date:         Tue, 18 Oct 88 10:11:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         EAE114@URIMVS
Subject:      Yale locks??

If I'm wrong, somebody correct me, but :
The 'Yale lock'  mentioned is not software, it's a physical
lock, on a door.  It was mentioned by way of analogy.
=========================================================================
Date:         Tue, 18 Oct 88 09:12:54 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Re: I am proud to be a hacker!
In-Reply-To:  Message from "Grep the Peg" of Oct 17, 88 at 11:33 am

>
>Right on.  I lost my account on the University of Calgary vaxes four
>times in my first year.  Once because I used "rlogin" when I wasn't
>supposed to.  Three other times because of unfounded "rumour".  It seems
>the sysops fastest way to get me into his office was to turn off my
>account.  I don't even think what I did classifies as hacking...
>

Us liberals (card carrying etc.) often find that the punishment is
supposed to follow conviction, not precede arrest.  Well, enough of
the democratic process, and enough of this.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
=========================================================================
Date:         Tue, 18 Oct 88 10:48:16 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Christian J. Haller" <CJH@CORNELLA>
Subject:      Re: Another vote.
In-Reply-To:  Message of Mon, 17 Oct 88 13:53:48 EDT from <MHQ@NIHCU>

>viruses, second ETHICS-L has been completely silent for months and

ETHICS-L has been far from silent.  Maybe you should resubscribe.
Maybe some of the rest of you should subscribe.  I'm enjoying the
discussions and sharpening my sense of fairness/justice.

On January 26, the host server became ETHICS-L@POLYGRAF (it had been
UGA before).  A reminder to others on the list:  DO NOT SEND SUBSCRIPTION
OR UNSUBSCRIPTION REQUESTS TO THE LIST unless you really want to make
thousands of copies of a simple administrative request (and make yourself
look dumb).  The correct form is (assuming CMS, and that you do not know
a list peer closer to you than POLYGRAF, wherever that is):

TELL LISTSERV AT POLYGRAF SUB ETHICS-L your name

Notice "AT" instead of "@", and of course substitute your name as you
want it to appear in files sent to you, in place of "your name".
You don't need to provide your Userid or node:  the LISTSERV picks them
up from the message envelope.
=========================================================================
Date:         Tue, 18 Oct 88 11:00:40 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Re: Yale locks??
In-Reply-To:  Message from "[e-mail]" of Oct 18, 88 at 10:11 am

>
>If I'm wrong, somebody correct me, but :
>The 'Yale lock'  mentioned is not software, it's a physical
>lock, on a door.  It was mentioned by way of analogy.
>

Right, I mentioned it.  The Yale lock is the conventional lock like
you find on most doors.  Blueprints of that lock are easily available
and any person who wants to know how it works can find out.  However
the height of a pin (which determines the depth of the notch in the
key at that point), can only be found out by disassembling that lock,
and thus, unless you can examine carefully an individual lock, you
cannot guess at the key.

My analogy was to a software protection package, in which the
technique is known, but the code word, or the file name used is an
individual choice on an individual machine.  Anyone can know that I
use a CRC protection algorythm, but what value I use for the CRC
polynomial is known only to me.  If that polynomial were public, a
virus writer could easily build a virus that overlays part of a
program, and changes just a byte or two to regenerate the same CRC.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
=========================================================================
Date:         Tue, 18 Oct 88 13:16:34 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ed Nilges <EGNILGES@PUCC>
Subject:      Re: I am proud to be a hacker!
In-Reply-To:  Message of Mon, 17 Oct 88 11:33:00 MDT from <BSWIESER@UNCAMULT>

Here's hoping that the virus scare does not result in a witch hunt
(and wizard hunt) for suspicious programmers, reminiscent of Joe
McCarthy's crusade against domestic Communism of the 1950s.  I don't
mean to imply that actual perpetrators of viruses should not be
detected and punished...I only mean that due process should be the norm.
For example, no virus case should lack expert witnesses in the
form of systems programmers testifying for the defense and prosecution.

Administrative proceedings should mimic court proceedings, and give
suspected programmers something like due process.  This is morally
justified by the fact that loss of a computer account can be a serious
matter for an individual; this is pragmatically justified since it will
prevent some unnecessary lawsuits by aggrieved individuals.

I don't agree that this thread should move to ETHICS-L.  We are writing
at the intersection of viruses and computer ethics.  If the thread
moves to ETHICS-L, then technicians uninterested in broad ethical
issues, who have administrative responsibility for the condign
punishment of virus hackers, will not have the benefit of the most
current legal and ethical thinking on this matter.  At most, the
discussion should be cross-posted to both groups.  It is true that
it raises the noise level of this group considerably, but this group
contained a high level of opinions, flames, and assorted nonsense
before the advent of this hacker discussion.

Edward Nilges
=========================================================================
Date:         Tue, 18 Oct 88 13:21:05 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Re: networks

>Because of these thoughts, I would object (again) to any suggestion
>that MS-DOS and MAC systems are more vulnerable to viruses
>than are any other systems.  How about changing the sentence
>in question to read:
>
>> No conventional computer installation that accepts
>> executable files from another system is safe.
>
>Forgive me if I harp on this, but I'm constantly reading and
>hearing how it's just these silly micros that are vulnerable to
>viruses, and that as soon as they get to be more like mainframes,
>we'll be safe.   It's not true...
>

I believe that the micros, at least those that have no user-system
differentation, like the PC and MAC, but unlike the microvax
do have an inherent flaw.  With these simpler systems, any code can do
anything.  Any program can wipe out the disk, change any file etc.

With the more sophisticated system (microvax), there is a user and a
system space, and the only way to affect system space is to be running
as a manager.  Of course we have seen how these systems can be
infected, but it requires a combination of errors, not just one, and
the careful user/manager can watch the system and keep it safe.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
=========================================================================
Date:         Tue, 18 Oct 88 14:50:31 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David M. Chess" <CHESS@YKTVMV>
Subject:      Micros and others (was: Re: networks)

Len Levine writes, about systems with more of the traditional
protection mechanisms than most micros have:
> Of course we have seen how these systems can be
> infected, but it requires a combination of errors, not just one...

I'm not sure I understand this.   Any environment in which a user
has normal write-access to executable files that other users have
normal execute-access to can become thoroughly infected with a virus.
It doesn't require any "errors" at all.

Traditional protection mechanisms can certainly make it easier
for people writing anti-virus software (because, for instance,
if the anti-virus code is in a protected kernal, no user-run
virus can turn it off), but by itself it doesn't do much to
slow viruses down at all.  In multi-user systems, where users
typically use lots of "goodies" owned and updated by other
users, I would maintain that a virus could spread *faster*
than in a loosely-linked collection of single-user micros.
See Fred Cohen's "Computer Viruses -- Theory and Experiments"
for some confirmation of that...

DC
=========================================================================
Date:         Tue, 18 Oct 88 13:08:51 MEX
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "J. Antonio D. Falcon Tena" <302581@VMTECMEX>
Subject:      Re: Yale locks??
In-Reply-To:  Message of Tue, 18 Oct 88 10:11:00 EDT from <EAE114@URIMVS>

Well I know yale locks are somo locks for doors,but maybe there have a new
meaning,you know people use too much words,and use them with double or triple
meaning.
=========================================================================
Date:         Tue, 18 Oct 88 12:56:00 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      Re: I am proud to be a hacker!

For what its worth, I am in agreement with Ed Nilges' discussion.  To improve
the signal to noise ratio and reduce the bandwagon effect, I am also in agree-
the signal to noise ratio we ought to reduce the bandwagon effect.
=========================================================================
Date:         Tue, 18 Oct 88 15:51:30 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Re: Micros and others (was: Re: networks)
In-Reply-To:  Message from "David M. Chess" of Oct 18, 88 at 2:50 pm

>Len Levine writes, about systems with more of the traditional
>protection mechanisms than most micros have:
>> Of course we have seen how these systems can be
>> infected, but it requires a combination of errors, not just one...
>
>I'm not sure I understand this.   Any environment in which a user
>has normal write-access to executable files that other users have
>normal execute-access to can become thoroughly infected with a virus.
>It doesn't require any "errors" at all.
>
>

My point was that if you are working in an environment where you may
log in as a user with limited priviledges, then you may establish one
"user" and run as him while you are testing software.  If the system
will not permit writing to a file without updating its last used date,
then you can see what files were affected, and if you cannot write
outside of the test directory, then you may be sure that no changes
occurred except in that area.

When done, the space can be cleaned.

In an unprotected system, no such security is possible.

Of course, if the virus is clever enough, then you can continue to use
it and then you may well find that the infection will reach as far as
you can reach.  That continued use is the "error" that I referred to
above.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
=========================================================================
Date:         Tue, 18 Oct 88 18:07:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Dimitri Vulis <DLV@CUNYVMS1>

This reminds me of an old Trojan Horse (not really a virus) which hit
some school (I forget which) many many moons ago. A student wrote a program
(some kind of useful tape utility) and submitted it to the systems people who
liked it a lot, installed it amongpublic utilities and used it heavily. Now,
the program, in addition to being a very useful tape utility, checked the date
and user's privilegesevery time it was run; and when it was run by one of
the priveleged usersafter the student graduated, it did some nasty things
to the entire system.
I guess there's a moral to it: if you can't trust the source of the program,
no amount of testing with user privs will help.

Re sysops locking out alleged hackers: if you use your mainframe account for
course-related work, and you don't do anything illegal, and systems people
interfere with your work (e.g. lock out your account, erase your files, etc)
the proper procedure is to SUE. There was a case about 2 years ago when a
CUNYVM operator nologged a student he did not like. The student sued (the
operator, not CUNY) and recovered the tuition for his computer course plus
computer usage fee plus damaged plus legal fees.
In my opinion, a systems person who does things like this is no better than
a virus (Trojan) writer. I conjecture that they have similar personality
traits.

-DV
=========================================================================
Date:         Tue, 18 Oct 88 17:46:00 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Bernie <BSWIESER@UNCAMULT>
Subject:      Re: Micros and others (was: Re: networks)
In-Reply-To:  Message of 18 Oct 88 14:51 MDT from "Len Levine"

I have to (really) disagree with the notion that mini's and larger are
safer that MAC and PC types.  Sure, with priv.s the system has a bit
more security, but remember why that is so...  Two people use the MAC
in our classics lounge.  Over 100 people use our Honeywell Multics
machine on good days.  On our suns and vaxes, the load isn't as much
but there are over 200 students relying on these networked machines.
Now the ration of two people losing a few files compared to two hundred
people makes virus (especially worms) more dangerous on mainframes &
mini's.

Note 1:  On the sun, priv.s don't mean too much.  They are easy to
bypass if the "true hacker" (no flames please) writes the virus.
Most UNIX machines are designed to be open, thus the question
"why have privs at all?"

Note 2:  Different tangent, when talking with WHMurray in private mail,
he suggested that infact writing a virus is morally wrong.  If ethical
issues, like writing a virus don't belong here, I'm confused...

Note 3:  Using external devices for viral data is not a close topic, is it?
I think it would be possible for things to hide in the laserwriter and
imagewriter.  Is it possible, using a smart device like a laserwriter,
to actually have a destructive piece of code working seperate from
the machine?  Ie.  it could mangle all printouts etc........
=========================================================================
Date:         Tue, 18 Oct 88 21:19:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         ACS045@GMUVAX
Subject:      RE:Peripherals

"BSWIESER@UNCAMULT" writes:

>Note 3:  Using external devices for viral data is not a close topic, is it?
>I think it would be possible for things to hide in the laserwriter and
>imagewriter.  Is it possible, using a smart device like a laserwriter,
>to actually have a destructive piece of code working seperate from
>the machine?  Ie.  it could mangle all printouts etc........

I don't know much about the internals of such things like laser printers, etc.,
but the idea seems sound...you could have one sitting off somewhere in memory
, or maybe have it infect a driver that would trash font loads or refuse to
accept them from the main machine,etc.  People have done it with clock/calendar
memory and even a first generation LaserJet is a lot smarter than that, so why
not peripherals??

Why even limit it to printers???...how 'bout a modem??---We just got a whole
bunch of new modems that have NO DIP switches, its all programmed from the
software....sounds like prime breeding ground to me!...theres got to be enough
memory in there to copy a whole command set which means there might also be
enough to house a virus.  Maybe something to echo a character or hangup or
something every x # of bytes transferred.

I don't claim to be a hardware expert, so pardon me if I screwed up and keep
your flame thrower holstered..

------------
Steve Okay  [e-mail]/[e-mail]/CSR032 on The Source.
                "Ahh...the keyboard, how quaint!"
=========================================================================
Date:         Tue, 18 Oct 88 23:28:23 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         me! Jefferson Ogata <OGATA@UMDD>
Subject:      Re: peripherals

Most peripherals, particularly modems, provide no code segment space for
host writing; printers and some modems allow the host to install 'data'
on them.  The nature of the data used for these peripherals -- fonts,
protocols, et al. -- is not rich enough to provide for self-replicating
code, or even damaging code.  In general, the worst a program could do
with a laser printer is install a bad font, which would be stomped if
a good font got loaded on top of it.  With a modem, the host could
define a bad protocol; this also would be temporary.  While there may
be peripherals where virus infection is possible, they are few and
far between, from what I've seen.  (Try infecting your accounting
package with a data file.  Not easy; usually impossible.)

Drivers, on the other hand, can be infected, but this occurs on the
host machine, not on the peripheral.

- Jeff Ogata
=========================================================================
Date:         Tue, 18 Oct 88 22:06:00 PDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         portal!cup.portal.com![e-mail]
Subject:      Infected peripherals

Jefferson Ogata writes:

>The nature of the data used for these peripherals -- fonts, protocols, et
>al. -- is not rich enough to provide for self-replicating code, or even
>damaging code.  In general, the worst a program could do with a laser
>printer is install a bad font, which would be stomped if a good font got
>loaded on top of it.

     The Apple LaserWriter uses PostScript.  PostScript is a complete
programming language.  The LaserWriter has a *significant* amount of memory
on board, like a meg or two (I seem to remember it being a meg when I
worked with one in 1986).  I can very easily imagine a virus written in
PostScript infecting a LaserWriter.


Dan Hankins
=========================================================================
Date:         Tue, 18 Oct 88 21:01:29 PDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         portal!cup.portal.com![e-mail]
Subject:      Are so-called protected systems protected against viruses?

In-Reply-To:  Message from "Len Levine" of Tue, 18 Oct 88 15:51:30 CDT

In article <[e-mail]> Len Levine
<sun!CUNYVM.CUNY.EDU!len%EVAX.MILW.WISC.EDU> writes:

>My point was that if you are working in an environment where you may
>log in as a user with limited priviledges, then you may establish one
>"user" and run as him while you are testing software.  If the system
>will not permit writing to a file without updating its last used date,
>then you can see what files were affected, and if you cannot write
>outside of the test directory, then you may be sure that no changes
>occurred except in that area.
>
>When done, the space can be cleaned.
>
>In an unprotected system, no such security is possible.

     Wrong.

     On an unprotected system (i.e. single-user micro) one does this:

     1. Archive the hard file or write-protect it (physically disconnect it
        from the system if necessary).
     2. Put the suspect program on a *copy* of one of your working disks.
     3. Run the program as much as you want.
     4. Compare the disk copy to the original.
     5. Compare the hard file archive to the current contents, if
        practical.
     6. If any files have been modified that should not have been, then you
        have a virus (or a buggy program).

     This is actually *more* secure than the multiuser scenario you
described.  In your scenario a virus could be sensitive to restricted
environments and not do anything nasty until run in a 'target-rich'
environment.  In mine it is running on what appears to be an ordinary
working system.

     My scheme is beatable also, in several ways.  But the user privs and
suchlike do *not* give the protected multi-user system more security than
the unprotected single-user variety.


Dan Hankins
=========================================================================
Date:         Tue, 18 Oct 88 23:56:00 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         KEENAN@UNCAMULT
Subject:      Re: peripherals
In-Reply-To:  Message of 18 Oct 88 21:28 MDT from "me! Jefferson Ogata"

Mainframe peripherals often have a very rich instruction set.  As an
example, tape drives are firmware-controlled and are basically
computers, hence indeed subject to viral infection.  We had a case once
in which we lost the firmware in a tape drive and it kept a $3M computer
off the air until we figured out how to put the firmware back in (via a
card reader of all things...)  so the loss of a peripheral in some cases
could be quite serious.
=========================================================================
Date:         Wed, 19 Oct 88 02:32:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         ACS045@GMUVAX
Subject:      Re:Infected Peripherals

>From:         portal!cup.portal.com![e-mail]
>Subject:      Infected peripherals
>To:           Steve Okay <ACS045@GMUVAX>

>Jefferson Ogata writes:

>>The nature of the data used for these peripherals -- fonts, protocols, et
>>al. -- is not rich enough to provide for self-replicating code, or even
>>damaging code.  In general, the worst a program could do with a laser
>>printer is install a bad font, which would be stomped if a good font got
>>loaded on top of it.

>     The Apple LaserWriter uses PostScript.  PostScript is a complete
>programming language.  The LaserWriter has a *significant* amount of memory
>on board, like a meg or two (I seem to remember it being a meg when I
>worked with one in 1986).  I can very easily imagine a virus written in
>PostScript infecting a LaserWriter.
>
>
>Dan Hankins


Which was sort of my original point, particularily with regards to laser
printers.  I'm a big TeX and LaTeX nut myself and it gobbles memory for
breakfast, and since the peripheral is the point here, PC or mainframe isn't
really that much of an issue. So, not only do you have a big huge chunk of
memory, but you've got something thats actually portable too...e.g. if you're
writing it in something like TeX or Postscript, you've got something that
can live in both a PC and multi-user environment, since the original code is
based on a standardized version(This is true at least w/ TeX...I've used an AT
to TeX out files when our VAX's LN03 was down of the software it was programmed
in.   Hows that for migration possibilities???
As for wiping it out on the next font load, don't most lasers have a chunk of
memory reserved specifically for default or standard fonts that are always
available, even when not switched on???
------
Steve Okay [e-mail]/[e-mail]/CSR032 on The Source.
                  "Ahhh...the keyboard, how quaint!''


=========================================================================
Date:         Wed, 19 Oct 88 02:57:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         ACS045@GMUVAX
Subject:      Re:Peripherals

>From:         KEENAN@UNCAMULT

>Mainframe peripherals often have a very rich instruction set.  As an
>example, tape drives are firmware-controlled and are basically
>computers, hence indeed subject to viral infection.  We had a case once
>in which we lost the firmware in a tape drive and it kept a $3M computer
>off the air until we figured out how to put the firmware back in (via a
>card reader of all things...)  so the loss of a peripheral in some cases
>could be quite serious.

You don't even need a mainframe, or even a large PC to be able to infect a
peripheral.  All it takes is a C-64.  The 1541 disk drive had a bank of 4k of
RAM and its own 6502. One method of copy protection used to be to write a small
part of the protection scheme into that area, and then have the loader check
for it, if it wasn't there, it'd assume a copy and freeze up.  A little off the
track there, but nevertheless a good example of what you can do with a little
space and some clever programming.
------
Steve Okay [e-mail]/[e-mail]/CSR032 on The Source
                "Ahhh....the keyboard..how quaint''

=========================================================================
Date:         Wed, 19 Oct 88 09:54:10 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe McMahon <XRJDM@SCFVM>
Subject:      Infecting a LaserWriter (was: Infected Peripherals)
In-Reply-To:  Message of Wed, 19 Oct 88 02:32:00 EST from <ACS045@GMUVAX>

LaserWriter users should remember that the LaserPrep file is downloaded
to the LaserWriter prior to any printing. It would be possible to install
a Trojan Horse in this code quite easily. With the new LaserWriter NTX,
it might be possible to store this code on the machine's hard drive.
Anyone know whether this is possible?

As far as a virus, however, you would have to have a file-access mechanism
in place to actually spread this virus back from the LaserWriter to the
host machine. On top of this, the virus would need to be able to find out
what kind of machine it is trying to infect. Does AppleTalk have such a
call?

In general, IMHO, I think you might have to watch out for Trojan PostScript,
but probably not viral PostScript. Are there any AppleTalk aficionados or
PostScript hackers out there who can tell us more?

--- Joe M.
=========================================================================
Date:         Wed, 19 Oct 88 08:53:27 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         me! Jefferson Ogata <OGATA@UMDD>
Subject:      peripherals again

Wow.  Looks like there's a lot of weird stuff out there I've never heard
of.  But ain't it always that way?

A virus in Postscript seems like a viable idea.  But a point I meant to
make and forgot was this: what's the point?  Most of the time, stuff
gets downloaded to the printer.  Now a virus can infect it all it likes,
but it's gonna get wiped as soon as the printer is turned off.  (There's
no reason for page memory to be non-volatile.  In fact, quite the con-
trary.)  I mean, what's it going to infect?  There's just the one
program; all a virus could really do is hang your printer until you
power-cycle it.  And there are plenty of other ways to hang a printer.
As far as printers are concerned, what's the practical difference
between writing a virus and writing a non-terminating Postscript program?
It's not clear to me what the virus-writer would achieve by writing
a virus for a printer.  However, a Postscript virus would have a larger
breeding ground; it could infect other Postscript files when a host
previewer gets run on it.  And in NeWS, there are lots more possibil-
ities, since NeWS is Postscript driven (+X11).

Another thing that is unclear to me is how a virus could infect
peripheral firmware.  (Unless it was there when the firmware was
produced.)

- Jeff Ogata
=========================================================================
Date:         Wed, 19 Oct 88 08:38:00 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Kent Cearley - UMS - 492-5262
              <[e-mail]>
Subject:      RE: Hardware Virus


        There are certain symbiotic relationships between device drivers,
        cpus, and peripherals that might make an infection more viable
        than it first appears. For example, some classes of device drivers
        allow a terminal to execute any program via an escape sequence
        followed by a command code and the programs name and parameters.
        This was a particular philosophy for dynamically reconfiguring
        device characteristics. Combine this with say, a programmable
        printer, which when prompted with a sequence from the host to
        identify printer type, sends the string with an escape sequence
        and a destructive procedure call, or a modem which has this
        same string defined as a setup sequence. While it is true that
        many hardware devices use RAM memory only for data, there are
        contexts ala von nuemann where data can become instruction.

        Perhaps the caveat is something Korzybski used to say,
         "You can never say everything there is to say about anything"

*-----------------------------------------------------------------------*
|  Kent Cearley                   |  [e-mail]          |
|  Management Systems             |                                     |
|  University of Colorado         |  Q: "How many surrealists does it   |
|  Campus Box 50                  |      take to change a light bulb?"  |
|  Boulder, CO 80309              |                                     |
|                                 |  A: "Fish."                         |
*-----------------------------------------------------------------------*
=========================================================================
Date:         Wed, 19 Oct 88 17:57:00 URZ
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         BG0@DHDURZ2
Subject:      PostScript and Viruses/Trojans

Hi folks,
as mentioned correctly by some people there seems to be no way
to write a virus that is able to spread back to the computer and
its storage devices. But there is another problem with PostScript
printers: You can damage a PostScript printer by programming it in
the wrong way so that you have to send it in to the producer. So it
is possible to write a virus that can find out if a PostScript printer
is installed and than damages the printer by programm (I don't want
to elaborate on this, but it is possible). As far as I know *no*
anti-virus programm prevents this...
All the best,
Bernd.
=========================================================================
Date:         Wed, 19 Oct 88 11:26:00 MST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Michael Kielsky <AGMGK@ASUACVAX>
Subject:      Great ideas!


I am glad that I subscribed to this list!  The number of great new ideas for
writing viruses is inspiring!  If I were gifted enough to be able to create
a virus, this would certainly be the place to get new ideas.

Michael Kielsky

P.S.  There were some :-)s implied.  Some.
=========================================================================
Date:         Wed, 19 Oct 88 14:53:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Paul Coen <PCOEN@DRUNIVAC>
Subject:      RE: Great ideas!


>I am glad that I subscribed to this list!  The number of great new ideas for
>writing viruses is inspiring!  If I were gifted enough to be able to create
>a virus, this would certainly be the place to get new ideas.
>
>Michael Kielsky
>
>P.S.  There were some :-)s implied.  Some.


        I certainly hope that the attitude of "don't discuss it and nobody
will do it" is not common in this discussion.  Has avoiding sex ed in this
country decreased the number of adolescents who engage in sex?  No.  All
it's done is given us a higher pregnancy rate than our European friends
such as Sweeden, France, etc.  If it didn't work in this case, what makes
anyone think it will work as far as computer viruses are concerned?  Give
people the best information possible so they can combat viruses.  If someone
is talented and malicious, they don't need the subscribers of this list for
their ideas.  They'd be perfectly capable of writing a virus on their own.

Ignorance is more dangerous than knowledge.

+----------------------------------------------------------------------------+\
|  Paul R. Coen                                                              | \
|                                                                            | |
|   Bitnet: PCOEN@DRUNIVAC       U.S. Snail:  Drew University CM Box 392,    | |
|           PCOEN@DREW                        Madison, NJ 07940              | |
|                                                                            | |
|       Just because you can't see it doesn't mean it isn't there!           | |
+----------------------------------------------------------------------------+ |
\                                                                             \|
 \_____________________________________________________________________________\

=========================================================================
Date:         Wed, 19 Oct 88 13:56:14 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Re: Are so-called protected systems protected against viruses?

In an article Dan Hankins writes:
>
>In article Len Levine writes:
>>
>> [..]
>>
>>In an unprotected system, no such security is possible.
>
>     Wrong.
>
>     On an unprotected system (i.e. single-user micro) one does this:
>
>[..]
>
>     This is actually *more* secure than the multiuser scenario you
>described.  In your scenario a virus could be sensitive to restricted
>environments and not do anything nasty until run in a 'target-rich'
>environment.  In mine it is running on what appears to be an ordinary
>working system.
>
>     My scheme is beatable also, in several ways.  But the user privs and
>suchlike do *not* give the protected multi-user system more security than
>the unprotected single-user variety.
>

How embarassing.

Dan Hankins makes a very good point here.  There is no difference in
the level of protection between the two systems for anyone who has
systemic authority in a secure environment.  For the low level user,
however, there is less to worry about on the protected system with
respect to his own errors, more with respect to errors of the
administrator.

Let me lick my wounds and work on this some more.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
=========================================================================
Date:         Wed, 19 Oct 88 15:24:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Jerry Leichter ([e-mail])" <LEICHTER@YALEVMS>
Subject:      RE: Re: I am proud to be a hacker!

BTW, another alternative to look at is Gnu C, which we have various copies of
around.  It is based on a lexer generator and Bison, a YACC rip-off.

                                                        -- Jerry
=========================================================================
Date:         Wed, 19 Oct 88 18:20:07 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         SHERK@UMDD
Subject:      peripherals again
In-Reply-To:  Message received on Wed, 19 Oct 88  10:35:27 EDT

 Jefferson Ogata <OGATA@UMDD> writes....
>A virus in Postscript seems like a viable idea.  But a point I meant to
>make and forgot was this: what's the point?  Most of the time, stuff
>gets downloaded to the printer.  Now a virus can infect it all it likes,
>but it's gonna get wiped as soon as the printer is turned off.  (There's
>no reason for page memory to be non-volatile.  In fact, quite the con-
>trary.)  I mean, what's it going to infect?  There's just the one
>program; all a virus could really do is hang your printer until you
>power-cycle it.  And there are plenty of other ways to hang a printer.
>As far as printers are concerned, what's the practical difference

I can see that you are from the land of Unix, where hosts and printers
have a master/slave relationship. But on Apple Talk each node has a
peer to peer relationship. Thus, a LaserWriter, with appropriate virus
code, could act like a fileserver with infected programs.

Erik Sherk
Workstation Programmer
Computer Science Center
University of Maryland
=========================================================================
Date:         Wed, 19 Oct 88 18:38:09 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         me! Jefferson Ogata <OGATA@UMDD>
Subject:      Re: hardware virus

>ala von neumann, where data can become instruction...

In some sense, data is ALWAYS instruction.  That is, 'data' defines the
control flow of some virtual machine defined and modeled by the 'code'.
Simple example: grep; data is a program saying to print out lines that
conform to certain restrictions.  This semantic model of programs as
machines holds for any program, though it gets obscure in many cases.

However, the main question is: does the language of the 'data' provide
adequate semantics to alter other 'programs'?  In some circumstances,
the answer is yes.  Grep output, when piped through another grep,
becomes another program with different output.  Compiler input becomes
a program that can run directly on the target machine.  Both are forms
of 'data' that can actuate control of the machine.

Now given the idea of interactive, very smart peripherals, one can
analyze whether the controls initiated by the peripherals are adequate
for modifying the GENERAL behavior of some unrelated program.  This
essentially qualifies as virus infection, particularly if the modified
behavior includes modification of further programs' behavior.  If,
however, the semantics of the peripheral control only allow damage or
reprogramming of other peripherals, especially in a one-way fashion,
it is more like Trojan damage.  And the latter may require host program
modification in order for it to occur.

But this note is getting kind of dull.

- Jeff Ogata
=========================================================================
Date:         Thu, 20 Oct 88 01:29:24 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         me! Jefferson Ogata <OGATA@UMDD>
Subject:      Apple Talk Attack

> I can see that you are from the land of Unix, where hosts and printers
> have a master/slave relationship. But on Apple Talk each node has a
> peer to peer relationship. Thus, a LaserWriter, with appropriate virus
> code, could act like a fileserver with infected programs.
> Erik Sherk

I'm fuzzy on how that would work.  Are you suggesting the LaserWriter
will reach out and infect other networked computers without being
asked?  If so, what protocols will enable it to do this?  If not,
why would any computer ask a LaserWriter for executable code?

- Jeff Ogata
=========================================================================
Date:         Thu, 20 Oct 88 09:03:39 edt
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         GATEH@CONNCOLL
Subject:      hardware vs. viruses

I seem to recall reading somewhere of a virus which infected a disk driver.
Apparently it increased the operating speed of the disk, such that the drive
wore out prematurely.  Anybody else heard of such things?  I'm very curious to
know what type of system was involved.  I assume it was a mini or larger, but
I can't help but wonder if similar things are possible on the micro level.  I
have this nightmare vision of such a thing going undetected for a year
or two, then micro hard disks crashing left and right all over campus,
and of course no one has backed up anything properly...


Gregg TeHennepe                        | BITNET:  gateh@conncoll
Minicomputer Specialist                | Phone:   [phone]
Academic Computing and User Services
Connecticut College
New London, CT


=========================================================================
Date:         Thu, 20 Oct 88 11:09:05 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Kevin Trojanowski <[e-mail]>

Subject:  RE:  hardware vs. viruses

>I seem to recall reading somewhere of a virus which infected a disk driver.
>Apparently it increased the operating speed of the disk, such that the drive
>wore out prematurely.  Anybody else heard of such things?  I'm very curious to
>know what type of system was involved.  I assume it was a mini or larger, but
>I can't help but wonder if similar things are possible on the micro level.  I
>have this nightmare vision of such a thing going undetected for a year
>or two, then micro hard disks crashing left and right all over campus,
>and of course no one has backed up anything properly...

>Gregg TeHennepe

The only drives I'm aware of which have the ability to change speed without
adjusting a potentiometer are Apple's 3.5" drives.  Even those drives
(for the Apple ][ series), while programmable I don't believe can adjust their
own speed via software.  As for hard drives with the capability to have their
speed adjusted, I know of none.

I have no idea about the possibilities of this concerning minis or mainframes.

By the same token, tho, wouldn't the same thing be accomplished by having the
drive do a series of random seeks?  Depending upon the drive, or the user,
this is something which might not be immediately noticed and would cause
undue wear on the drive.

-Kevin Trojanowski
 [e-mail]

=========================================================================
Date:         Thu, 20 Oct 88 11:24:15 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Mark S. Zinzow" <MARKZ@UIUCVMD>
Subject:      Brain Virus at UIUC

The Pakistani Brain Virus has been discovered by the PC Consultants
on a disk a student had been using in the Forein Language Microcomputer
Lab.  This is the first known occurance of an IBM PC based virus infection
on this campus.  I suggest avoiding public use PC's for a few days
until effective counter measures can be implemented.  Immediate backup
of personal hard disks, write protect all original disks, and be very
careful about exchanging files until we can provide details on checking
for the presence of the Brain Virus.  The Microcomputer Resource Center
has a two disk set of anti-virus programs and information which may be
helpful.  These may be copied safely on a two drive PC there when booted
from a write protected original DOS disk.

-------Electronic Mail----------------------------U.S. Mail--------------------
ARPA: [e-mail]         Mark S. Zinzow, Research Programmer
BITNET: [e-mail]         University of Illinois at Urbana-Champaign
CSNET: [e-mail]      Computing Services Office
 "Oh drat these computers, they are  150 Digital Computer Laboratory
   so naughty and complex I could    1304 West Springfield Ave.
  just pinch them!"  Marvin Martian  Urbana, IL 61801-2987
USENET/uucp: {ihnp4,convex,pur-ee,cmcl2,seismo}!uiucdcs!uiucuxc!uiucuxe!zinzow
(Phone: [phone]  Office: CSOB 110) ihnp4!pyrchi/         \markz%uiucvmd
=========================================================================
Date:         Thu, 20 Oct 88 17:46:07 MEZ
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Dr. Gregor Reich" <A8411DAA@AWIUNI11>
Subject:      Re: hardware vs. viruses
In-Reply-To:  Message of Thu, 20 Oct 88 09:03:39 edt from <GATEH@CONNCOLL>

Dear fellows,
please be reasonable. There is no way a softwareproduct can influence
the rotational speed of a hard disk neither on a PC nor on a greater machine.
There is a possibility to change the speed of the 1.2MB Floppy on an AT, but
it can only set one of two speeds and not some completely different value.
All we have to deal with is the software side, and this is bad enough.
           G. Reich
           Institut for Analytical Chemistry
           University of Vienna, Austria
=========================================================================
Date:         Thu, 20 Oct 88 13:58:44 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ken van Wyk <[e-mail]>
Subject:      Re: hardware vs. viruses
In-Reply-To:  Your message of Thu, 20 Oct 88 17:46:07 MEZ

> There is no way a softwareproduct can influence
> the rotational speed of a hard disk neither on a PC nor on a greater machine.

It's possible that the person who brought this subject up wasn't
referring to rotational speed.  I remember in my CP/M days that the
operating system could be configured for a particular track-to-track
seek time since some drives were slower than others.  The default, if
memory serves me correctly, was 30 ms and could be bumped down to 6 ms
for faster drives - that made one hell of a difference in the drive
speed.  As I recall, these numbers were dependent on the floppy disk
and the disk controller's firmware.  That is, 29 ms is not a valid
time, but 30 is.  Nonetheless, setting a drive up for 6 ms when it
couldn't quite keep up with that speed could conceivably make the
drive very unhappy.  I don't think that this would cause hardware
damage, though, only seek errors on the drive.

Ken




Kenneth R. van Wyk                   Calvin: Says here that there are four
User Services Senior Consultant         pecks in a bushel.  What's a peck?
Lehigh University Computing Center   Hobbes: A quick smooch.
Internet: <[e-mail]> Calvin: You know, I just don't understand
BITNET:   <LUKEN@LEHIIBM1>              this math stuff!
=========================================================================
Date:         Thu, 20 Oct 88 12:58:58 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Re: hardware vs. viruses
In-Reply-To:  Message from "Dr. Gregor Reich" of Oct 20, 88 at 5:46 pm

>please be reasonable. There is no way a softwareproduct can influence
>the rotational speed of a hard disk neither on a PC nor on a greater machine.
>There is a possibility to change the speed of the 1.2MB Floppy on an AT, but
>it can only set one of two speeds and not some completely different value.
>All we have to deal with is the software side, and this is bad enough.
>           G. Reich

Let us not become too cool here.  It is possible for example for
software to damage some (older fashioned) crt devices by changing
sweep rates, it is not an unreasonable question to ask about other
tuneable phenomena.  I agree that I am unaware of any disk drive that
has its speed tunable, but I do not believe that this is not either
possible or beyond comprehension.  As hardware becomes more
sophisticated, the capabilities may well become available.

Let's scoff more slowly.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
=========================================================================
Date:         Thu, 20 Oct 88 14:15:19 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         SHERK@UMDD
Subject:      Mac viruses..

     Has anyone heard of a Mac virus that puts up a dialog box with
"Sax Flash"? There is a rummor of one here at U of Maryland.

Erik Sherk
Workstation Programer
Computer Science Center
University of Maryland
=========================================================================
Date:         Thu, 20 Oct 88 11:58:00 PDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ed Sakabu <CSMSETS@UCLAMVS>
Subject:      Re: Re: hardware vs. viruses



> >please be reasonable. There is no way a softwareproduct can influence
> >the rotational speed of a hard disk neither on a PC nor on a greater machine.
> >There is a possibility to change the speed of the 1.2MB Floppy on an AT, but
> >it can only set one of two speeds and not some completely different value.
> >All we have to deal with is the software side, and this is bad enough.
> >           G. Reich
I do recall in the old days (~8 years or so ago) we had a DEC 10 that
ran tops 10 and you could crash disk heads by forcing the heads to
seek from the inside to the outside tracks at a certain frequency. If
there was a minimal amount of other seeks this would crash the disk.
   --Ed
=========================================================================
Date:         Thu, 20 Oct 88 12:27:14 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         SHERK@UMDD
Subject:      Apple Talk Attack
In-Reply-To:  Message received on Thu, 20 Oct 88  01:39:10 EDT

 Jefferson Ogata <OGATA@UMDD> writes...
>I'm fuzzy on how that would work.  Are you suggesting the LaserWriter
>will reach out and infect other networked computers without being
>asked?  If so, what protocols will enable it to do this?  If not,
>why would any computer ask a LaserWriter for executable code?

No, I am not suggesting that. What I meant was that the LaserWriter would
mask out the real file-server and that Macs would execute code from
the LaserWriter that was acting like their "safe" file-server.
    Now that I think about it, this would be a really neat use of
the new NTX with a hard disk ( not to distribute virus code but just
act like a file-server! :-).

Erik Sherk
Workstation Programer
Computer Science Center
University of Maryland
=========================================================================
Date:         Thu, 20 Oct 88 16:16:52 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject:      Brain virus hits Hong Kong (reprinted from RISKS forum)


     This was in a recent RISKS forum:


Date: Tue, 18 Oct 88 13:34:27 est
From: Dave Horsfall <[e-mail]>
Subject: "Brain" virus shows up in Hong Kong

On the off-chance that you haven't had enough of virus reports, here's
another one from Computing Australia, 17th October, 1988:

``HK consultants hit by overseas virus

  A leading firm of financial consultants has become the first main-
  stream business in Hong Kong to be affected by a computer virus.
  The Business International consultancy reported last week the "Brain"
  virus -- well-known elsewhere in the world, but never before seen
  in Hong Kong -- had appeared on some disks.  ...  BI was playing down
  the significance of the find last week, with a company spokeswoman
  saying the virus had not reappeared and that no data had been lost.''

The article goes on further to discuss the origin of the Brain virus,
and makes the amazing observation "[it] does not destroy data, but
scrambles it beyond recognition".  I dunno, I would certainly regard
data "scrambled beyond recognition" as being "destroyed".

Dave Horsfall (VK2KFU),  Alcatel-STC Australia,  [e-mail]
[e-mail],  ...munnari!stcns3.stc.OZ.AU!dave

Kenneth R. van Wyk                   Calvin: Here, try this new cereal,
User Services Senior Consultant         Chocolate Frosted Sugar Bombs.
Lehigh University Computing Center   Hobbes: Gack!  Ptui!  :-(
Internet: <[e-mail]> Calvin: Yeah, they're a bit bland until
BITNET:   <LUKEN@LEHIIBM1>              you scoop some sugar on them.
=========================================================================
Date:         Thu, 20 Oct 88 16:37:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Robert Stratton <RSTRATTO@NAS>

Subject: Re: hardware vs. viruses

>I seem to recall reading somewhere of a virus which infected a disk driver.
>Apparently it increased the operating speed of the disk, such that the drive
>wore out prematurely.  Anybody else heard of such things?  I'm very curious to
>know what type of system was involved.  I assume it was a mini or larger, but
>I can't help but wonder if similar things are possible on the micro level.  I
>have this nightmare vision of such a thing going undetected for a year
>or two, then micro hard disks crashing left and right all over campus,
>and of course no one has backed up anything properly...

>Bob Stratton

 I do recall an instance of a Trojan horse on the old TRS-80 Model I,
 which would do a series of random, long distance seeks on floppy
 drives. The drives in question, if left unattended, as many BBS
 machines were, would eventually overheat and in several
 cases, began to smolder. Disk drive technology has improved
 considerably since then, but so has the instance of
 unattended operation of PC's.
                                        Bob Stratton
                                        <RSTRATTO@NAS>


=========================================================================
Date:         Thu, 20 Oct 88 14:34:00 PDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "JOHN D. WATKINS" <WATKINS@UCRVMS>
Subject:      kill that drive!

  On the subject of damaging disk drives, a couple months ago I read
(I think in Computers & Society Digest) about a prank you could play
with drives; you figure out a good resonant frequency for the drive,
then make the head(s) seek at just that rate.  The drive starts vibrating
(relatively) violently, enough so that it creeps across the floor,
possibly unplugging itself and certainly puzzling the operators in
the morning!
  I believe that this referred to mainframe drives, but it has interesting
possibilities for micros as well; if you could make a drive vibrate
for long enough you might be able to throw it out of alignment or
something evil like that...

   Kevin
=========================================================================
Date:         Thu, 20 Oct 88 17:16:00 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      RE: kill that drive!

Regarding the software destruction of drives...some of the PC disk diagnostics
can approach what seems to be a self destructive mode.  When running the seek
test, the drive does indeed start to vibrate and becomes rather loud.  I
suppose that a virus inplanted in an unattended machine could do the same.  I
have never had enough courage to run this test more than once every so often. I
don't know what would happen if the drive were continuously run this way.  I
can't imagine it would be very good for it.
Allen Gordon
=========================================================================
Date:         Thu, 20 Oct 88 20:23:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Dimitri Vulis <DLV@CUNYVMS1>
Subject:      Software damaging floppy drives on a PC

The FDC on IBM PC and clones has a parameter called 'head unload time'.
BIOS sets it to a conservatively high value; MS DOS 2.0 and later
resets it to a lower value. Soon after DOS 2.0 came out, some people
figured that they can make their drives operate faster by setting it
lower yet; and it did, but the affected drives went out of alignment
withina few month. I don't see why this was referred to as 'virus',
though. (Although, this certainly is a technique that a virus or a
Trojan horse could use to damage the machine).
=========================================================================
Date:         Thu, 20 Oct 88 21:34:00 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Gordon Meyer <TK0GRM1@NIU>
Subject:      More on hardware damage

Just to add a little fuel to the virus/hardware damage thread, I'd
like to point out that it is supposedly possible to fry a monitor,
on the Atari ST system, by forcing the computer into the incorrect
mode.  In other words, if you have a monochrome monitor hooked up
the hardware will detect this and adjust the sync rate of the
computer to match.  But it is supposedly possible to "trick" the
computer, via software, into thinking that a color monitor is
being used.  Evidently the differing sync rates of the two monitors
will cause permanent damage if this occurs.
-=->G<-=-
I'm not a software developer, and I'm no hardware wizard.  I'm sure
the concept is correct but don't flame me for saying zig would I
should have said zag.  Polite corrections are welcome.
I imagine the concept could apply to other systems as well.
=========================================================================
Date:         Thu, 20 Oct 88 23:11:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Paul Coen <PCOEN@DRUNIVAC>
Subject:      RE:  More on hardware damage


If I'm not mistaken, on the old IBM monochrome monitors one could (and someone
did) write code (I can't recall if it was a virus, trojan horse, or what), that
altered the scan rate on the screen, and if this was allowed to continue, it
could heat the monitor up to the point where it could (and on occasion did)
burst into flames.  I wish I could recall this a little better than I do,
I can't even remember the specific monitor.  Anyone else out there read/hear/
have this happen to you?

+----------------------------------------------------------------------------+\
|  Paul R. Coen                                                              | \
|                                                                            | |
|   Bitnet: PCOEN@DRUNIVAC       U.S. Snail:  Drew University CM Box 392,    | |
|           PCOEN@DREW                        Madison, NJ 07940              | |
|                                                                            | |
|       Just because you can't see it doesn't mean it isn't there!           | |
+----------------------------------------------------------------------------+ |
\                                                                             \|
 \_____________________________________________________________________________\

=========================================================================
Date:         Fri, 21 Oct 88 08:40:40 MEZ
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Dr. Gregor Reich" <A8411DAA@AWIUNI11>
Subject:      Re: More on hardware damage
In-Reply-To:  Message of Thu, 20 Oct 88 21:34:00 CDT from <TK0GRM1@NIU>

I think I have to clear up a few things about my remark on "no way to
influence the hardware". What I feel the danger of a virus is, that
something goes on which can not be stopped until it's to late. This
can happen (on the hardware side) by changing the seek time of a drive
to a value which influences its performance over time. The other
possibilities, i.e. bringing the heads in a resonance status or frying
the monitor (you can do the same on a Hercules card), would not be
unnoticed by the people in front of the screen. If you have a BBS or
something else running unobserved, thats of course another story.
          G. Reich
          Institute for Analytical Chemistry
          University of Vienna, Austria
=========================================================================
Date:         Fri, 21 Oct 88 10:08:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Shatner and Nimoy in '92! <PGOETZ@LOYVAX>
Subject:      Software frying Commodores

        Remember the Commodore Pet?  It was made back around 1977.  Referencing
a certain memory location made the 6502 run at 2 Mhz (I think) instead of
1 Mhz.  The only drawback was that
1. the machine was unreliable at that speed, and
2. on certain models of the Pet, doing so could fry certain chips.
=========================================================================
Date:         Fri, 21 Oct 88 12:24:08 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Mark F. Haven" <MHQ@NIHCU>
Subject:      PC disk diagnostics- destructive?

>Date:         Thu, 20 Oct 88 17:16:00 MDT
>Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
>From:         [e-mail]
>Subject:      RE: kill that drive!
>
>Regarding the software destruction of drives...some of the PC disk diagnostics
>can approach what seems to be a self destructive mode.  When running the seek
>test, the drive does indeed start to vibrate and becomes rather loud.  I
>suppose that a virus inplanted in an unattended machine could do the same.  I
>have never had enough courage to run this test more than once every so often. I
>don't know what would happen if the drive were continuously run this way.  I
>can't imagine it would be very good for it.
>Allen Gordon
>

When I worked for a company which sold PC's we burned them in before
delivery by stressing them as much as possible.  One of the things
we did to test drives was to run the diagnostics continuously
overnight.  It turned up some defective machines (which we returned)
but I don't remember the ones we sent on to our customers coming
back with problems in the drives at a higher rate than the machines
I fixed which we had not burned in.

Based on this I conclude that the PC diagnostic seek test is
non-destructive (despite the noise).  If anyone has any actual
experience to the contrary PLEASE post it.
=========================================================================
Date:         Fri, 21 Oct 88 14:31:43 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ken van Wyk <[e-mail]>
Subject:      Aldus gets hit again

I've just received a word-of-mouth announcement that Aldus Corporation was
hit by another virus.  The original announcement, I'm told, came from the
Associated Press board on Compuserve.  The details that I have are sketchy,
but they say that the virus was called nVir (?).  If anyone has any more
information on this, *please* send it to the list!

Also, the same announcement on Compuserve said that Carnegie Mellon University
(in Pittsburgh PA) was also hit by a virus this last week.  No more details
on that one, though.  Does anyone have any more information on this?

The Compuserve message was dated today, 10/21/88.

Ken



Kenneth R. van Wyk                   Calvin: Says here that there are four
User Services Senior Consultant         pecks in a bushel.  What's a peck?
Lehigh University Computing Center   Hobbes: A quick smooch.
Internet: <[e-mail]> Calvin: You know, I just don't understand
BITNET:   <LUKEN@LEHIIBM1>              this math stuff!
=========================================================================
Date:         Fri, 21 Oct 88 13:46:17 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Kevin Trojanowski <[e-mail]>
Subject:      Software effects on hardware


A few years back, I remember hearing some acquaintances talking about a method
of "punishing" someone they didn't like -- they would give him copies of
pirated software which had the boot sector (or some such) changed so that when
he would boot the disk, the drive would be told to seek track 99.

On the old Commodore-64 drives, this caused the drive head to fall off the
glides, damage itself on the stops, or some equiavalent thereof -- in any case,
it ruined the drive.

-Kevin Trojanowski
 [e-mail]
=========================================================================
Date:         Fri, 21 Oct 88 15:22:51 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe McMahon <XRJDM@SCFVM>
Subject:      Re: Aldus gets hit again
In-Reply-To:  Message of Fri,
              21 Oct 88 14:31:43 EDT from <[e-mail]>

>... they say that the virus was called nVir (?).  If anyone has any more
>information on this, *please* send it to the list!

Boy, I don't understand that at all. nVIR is a well-known Mac virus that
can be fought quite successfully with the "Vaccine" CDEV. If this is the
known strain of nVIR, Aldus isn't being very careful about viruses.

For those who know about nVIR, you may delete the rest of this message.

nVIR is a virus supposedly based on some assembler source which was
posted in CompuServe last year sometime. It follows standard spread
patterns (application -> system, system -> applications), but has a
few bugs. It doesn't check for a "killed" version of itself and does
not completely infect applications which have protected code resources.

Its "function" is to (on a 1-in-16 chance) say "Don't panic" if MacInTalk
is installed, and to beep if it isn't. The LISTSERV here at SCFVM has both
a program to remove it from your applications and a better explanation (in
the virus documentation stack). You must use ResEdit to get it out of your
System files.

Again, since source of sorts was available for this one, it may have been
modified to be more sophisticated and more agressive; it is also possible
that it has been made Vaccine-proof.

--- Joe M.=========================================================================
Date:         Sat, 22 Oct 88 04:20:13 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments:     <Parser> W: Invalid RFC822 field --
              "================================================================
              =========". Rest of header flushed.
From:         "Pedro Sepulveda J." <PSEPULVE@USACHVM1>
Subject:      JV Virus...

              We are  a group of  student of the  'Universidad de
    Santiago  de  Chile'  with   a  special  interest,  'Computer
    Viruses'.

              Our  investigations are  oriented on  the Jerusalem
    Virus (also  known as  the 'Hebrew University  Virus'), since
    that JV only has come at this moment. Due to circumstances of
    the educational  ambient, we  want to  protect our  works and
    resources.

              We are disassembling the greater part of the JV.

              If  you are  interested in  our work  and you  have
    information too, we would can to join efforts for to learn of
    the viruses  instead of to  be prejudiced  for its and  so to
    direct this knowledges for good road.

Pedro Sepulveda J.
Universidad de Santiago de Chile
=========================================================================
Date:         Sat, 22 Oct 88 19:27:04 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         SSAT@PACEVM

It seems to me that on a pc type system the following steps should
stop the virus's that are floating.

1) Make command.com and system files READ-ONLY.

2) Use FLUSHOT (direct from author)

3) Use common sense.

The combination of the 3 steps above just caught a virus in a copy of
Norton Commander someone sent to me. This is a new and nasty virus and
you will hear more as soon as I get the time.
=========================================================================
Date:         Sun, 23 Oct 88 13:07:17 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Jean Coppola <SSAT@PACEVM>
Subject:      virus

Well we have a little more on the Norton virus. It eats command.com
and the system files, as well as destroying both Fat tables and all know
backups like Mace utilties and Disk optimizer produce.

This is a little more vicious than most because a FULL format of the hard
disk is required after being attacked. By full I mean both low level and
dos formats must be done. Otherwise the little bugger is still on the disk
(boy did we find out the hard way) and will reattack you at a later date.
=========================================================================
Date:         Sun, 23 Oct 88 18:00:15 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David A. Bader" <DAB3@LEHIGH>
Subject:      Virus Conference

I would like to thank the eight out-of-town individuals who I met at the
virus conference this weekend in the Lehigh Valley, Pa.  I can't say
that I learned anything that I didn't read on virus-l, but being able
to discuss these topics in a little greater depth and on a closer basis
was very informative.  I handed out disks to most of the participants
with a collection of public domain anti-viral/trojan packages and would
appreciate any comments and evaluations of these products sent to me.
( -Especially on FluShot Plus 1.4; it seems as though no one will try
this package, even though it has most of the bugs worked out from the
older versions.)
  Thanks a lot,
 David Bader
   DAB3@LEHIGH
   [e-mail]

P.S. To the Calgary Contingency: When Chris and I make our ways out
there... we'll be sure to call.
=========================================================================
Date:         Sun, 23 Oct 88 23:15:20 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Loren K Keim   -- Lehigh University <LKK0@LEHIGH>
Subject:      The Virus Conference - thank you

Actually David, I'm intreged by your comments:

You mentioned something about all that we discussed were old
virus-l topics, and I don't believe that's ctrue.   Since you
weren't present for quite a bit of the conference, you may
have missed some of the things we discussed, but we did
go over organizations tracking viruses, integrity systems
including the Bell-Lapadula, Limited Transistivity, Complexity
Based Integrity and Separation (I think we have baredly touched
on these on the list), and we did talk about Wroms in greater
detail than on the list.

We ended up having a total of 14 people show up for the conference
(although several people were there only half the ftime).

I had gotten worried early on that the conference might have
problems, we had two people call and cancel at the last minute,
two that said they were coming never showed (JD Where are you?),
and two groups that said they'd send representatives didn't.
We had the additional progblem that the printer company I
usd to print and bind the books seems to have broken their
tape binding machine and we had to give out the book in
loose form in folders.

However, as one person stated "Its easier to talk, discuss
subjects and get points across in smaller groups", and I
think it went quite well.  We had an excellent group of
people with a greatly varied knowledge of the subject
viruses

I do want to say thanks to everyone who came!  It was
really appreciated, and I hope you all took something
out of the conference.

The conference ended up being more informal than oformal
and I believe that worked quite well with this group of
people.  Its always interesting to meet people who you
have been discussing subjects with for some months without
meeting then face to face.    Thanks goes to Chris Haller
of Cornell who corrected many of my spelling atrocities
(that word isn't even close is it?_)  Also, Steve Okay
from the Source took notes on his laptop throughout the
3 days and apparently will be making the mnotes available
in the future.  Because it was lengthy, I believe it will
take him some time to confvert his notes to something
readable.  (Please excusse my typing, I seem to be missing
the backspace key)

Thanks to all who made this conference psossible!

Loren Keim
=========================================================================
Date:         Sun, 23 Oct 88 23:41:43 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Loren K Keim   -- Lehigh University <LKK0@LEHIGH>
Subject:      The Book / Effects of the Conference

Reading through my notes and letters to me, several people
have asked if I think we'll see any effects of the conference.
I'd like to forward this statement through the list to everyone
who did come and ask them if they think it helped them.

For me, I got a number of ideas and quite a bit of help on
correcting mahny of the ideas I had previously.  Joe Sieczkowski
gave us some unique ideas on Unix protection schemes, which
I greatly enjoyed and we may see something come of that over
the next year.  I believe the group helped him to look at
different aspects of what he wanted to do .  Hopefully
we've also given people that little bit of information that
they might need to help prevent viruses in the future.  I
believe there were a few good points about network security,
and we may see more security at some colleges through
networks due to some of our discussions.  I really felt it
was much easier to disucss the problems in group than to
write them in short letters over the net.

As for the book, we've gotten numerous request s for it.
We have located another printer and gotten some prcice
quotes today for anyoje interested.  I want to point out
that the price I am setting the book / notes at is about
5 prercent higher than MY cost.  I'm doing that to cover
the expense of the conference  (I ran into the hole on
it slightly), and to make sure I am covered, as I always
seem to underestimate the costs.  I'm pointing aout that
I'm not making money off this for the simple reason that
we can't advaertize over bitnet and I've already had one
woarning that I may not do so  .

The book is broken down into a few sections:
  -  Introduction to Computer Viruses (Definitions, Detection methods)
  -  Background and Experiments (From Von Neumann through Kraus through
       Cohen, including Computer VWorms, Core Wars and so on)
  -  Major Viruses and Resultant Detection Schemes (Mainframe
       and Micro viruses including the source code to the Christma
       Exec which now should be powerless and has been published
       elsewhere, and a look at 2 versions of the Brain, Lehigh,
       Aldus and the Israeli)
  -  Early Defense Methods (Partition Models and Flow Models)
   - Practical Defense Methods (Comlplexisty Based Integrity and
       other ideas)
  -  The Future (Secure Systems in danger, dangers viruses pose)

and 4 appendices :

  -  Term Glossary
  -  List of Known Viruses
  -  Viruses in the Classroom
  -  Virus Law

I will also include a paper that Pam Kane sent me.

(Those of you who have already gotten thr packet, as I said,
I am going to enhance the "Furture " Section, and niclude
the 3 missing appendices in the mail this week)

The known viruses section is a bit schetchy in that it doesn't
include quite a few viruses in existance.  I would like to
see a break down or flow chart of how each virus works from
a reputable source before I s include it, so anyone who has
worked with one recently, please send me what you can to LKK0
at LEHIGH.  I do inlcude a number of viruses howevera and
their breakdowns).

Prices:

   The Book - Tape Bound / Soft Back / Printing on Right
              apage only...    18.50
   The Bok  - Tape Bound / Soft Back / Printing on Left
              apage only  (some requested this bcause
              its easier to take notes on the right)...  22.50
              (The publisher has to actually physically turn
              hafl of it around and wants more to do that)
  The Book - Spiral Bound / Soft Back / Printed on Right... 20.00
  The Book - Spiral Bound / Soft Back / Printed on Left...  22.50
  The Book - Har d Bound  / Hard Spine / Printed on Right...
                               45.00
  The Book - Hard Bound / Hard Spine / Printed on both sides...
                               48.00
  The Book - Spiral Bound / Printed on both sides...  22.50
  The Book - Tape Bound / Soft Back / Printed on both sides ... 21.00


     For anyone who wants a copy oin the US... please send 4.50
to cover P&S...  I will return the unused portion if any.  In
Canada or Germany (or anywher for that matter, I just happen to
have people in both who want copies) I don't have a n exact
quote yet on mailing costs so hold off a little while.

     Send it to :    Loren K Keim
                     P.O. Box 2423
                     Lehigh Valley, Pa 18001

Incidently, when I talk about defense methods in the book, I
just describe them, I don't prove them matehematially, although
I've been asked at times to do so.  I will be trying to put
together a book later this year (with much better editing)
which will be about defense methods, including some ideas I've
had and several that have been send to me (with full report
going to the author of each) and will be shoing the math.  I
ll try to pubisdh that if I can.

    If yo have any questiosn, don't hesitate to write:...

Loren Keim
=========================================================================
Date:         Mon, 24 Oct 88 02:35:00 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         GREENY <MISS026@ECNCDC>
Subject:      Dissertation Copy?

Does anyone know of where I could obtain a copy (if this is possible...) of
Fred Cohen's dissertation on "Computer Viruses -- Theory and Experiments"?

Thanx in advance....

Bye for now but not for long
Greeny

Bitnet: miss026@ecncdc
Internet: [e-mail]
Disclaimer: Do I really need one?
=========================================================================
Date:         Mon, 24 Oct 88 03:01:00 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         GREENY <MISS026@ECNCDC>
Subject:      even *MORE* on hardware damage

All this talk of "programs" causing damage to hardware has caused a few
of the ole cobwebs to clear out of the history section of my brain which
caused a story that I heard a long long time ago in a CS101 class to surface..

"...It seems that a programmer who delighted in taking excessively long lunch
hours discovered a way to shut down the computer for hours at a time.  It
happened that the programmer -- in those days also being somewhat of an
Electrical Engineer -- discovered exactly which MAGNETIC CORE was closest to
the High-Temp shutdown sensor, and wrote a program which continously wrote
an alternating pattern of binary 0's and 1's to *THE* core, until it got hot
enough to trigger the High-Temp shutdown sensor.  The sensor, being decieved
into thinking that the entire machine was overheating, promptly shut it down"

...An oldie, but a goodie...

Bye for now but not for long
Greeny

Bitnet: miss026@ecncdc
Internet: [e-mail]
Disclaimer: If you happen to still have some core memory machines being used
            and you pull this trick -- forget where you read this! :->
=========================================================================
Date:         Mon, 24 Oct 88 13:19:00 PDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      ANTI-VIRUS PROGRAM ARCHIVE

< I THOUGHT THE FOLLOWING MIGHT BE OF INTREST TO VIRUS-L MEMEBERS....>



From:   IN%"ADVISE-L@NDSUVM1"  "User Services List" 24-OCT-1988 13:00
Subj:   Re: Virus...
Date: Fri, 21 Oct 88 23:39:29 CDT
From: David Boyes <[e-mail]>

The  archive  server  at  RPICICGE  (and  indirectly  SIMTEL20.ARMY.MIL)
maintains a  huge collection  of anti-viral  programs that  should prove
equal to most viroid strains.

Directions for using  the RPI archive server can be  found in the latest
issues of NetMonth (published by the famous Chris Condon [BITLIB@YALEVM]
and available  from better servers  near you, esp.  LISTSERV@MARIST). If
you   have  access   to  the   Internet,   the  files   are  stored   on
simtel20.army.mil,  IP  address 26.0.0.74.  Log  in  as user  ANONYMOUS,
password is your  real userid and node. All the  virus-related files are
stored in the directory PD1:<MSDOS.TROJAN-PRO>.

For those  of you getting the  programs via the Internet,  remember that
SIMTEL20.ARMY.MIL  is a  DEC-20 and  uses 36-bit  words. You  *must* use
TENEX mode when you FTP the files or you *will* get garbage -- issue the
TENEX command before doing the GET for the file you want.
----------

David Boyes       [phone]     |BITNET: DBOYES@RICE
Systems Group                        |Internet: [e-mail]
ICSA - Rice University               |

  UUCP: [your fav backbone]...!psuvax1!uncle-bens.rice.edu!dboyes
=========================================================================
Date:         Mon, 24 Oct 88 16:10:34 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Kevin Trojanowski <[e-mail]>
Subject:      RE: CMU and the virus


I just talked with a friend of mine who happens to be a student at CMU about
viruses, and CMU did indeed get hit.

I'm not sure what virus it was, but it infected their Macs, including some
file servers.

It seems the virus got onto one of the servers, and a new version of software
for a class was to be distributed.  Their distribution method is such that
the software is placed on the server, and all students needing it can then
copy from the server for their own uses.

Well, the server containing the distribution copy of Genie (a Pascal
interpreter of sorts) was contaminated, and thus an infested copy of Genie
got quickly and widely spready around campus.

I know this is somewhat sketchy, but it's all I have for now.  Perhaps someone
a little closer to the Pittsburgh area can get more information?
=========================================================================
Date:         Mon, 24 Oct 88 14:16:00 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         KEENAN@UNCAMULT
Subject:      Re: The Virus Conference - thank you
In-Reply-To:  Message of 23 Oct 88 21:15 MDT from "Loren K Keim -- Lehigh
              Univer

Loren, I think you did an excellent service in organizing the
conference.  The three of us from Calgary (Grey Lypowy, Corey Wirun and
myself) found it very helpful to be able to work some ideas back and
forth without the delays and mis-communications inevitable in this
electronic medium.  Also, it gave us a good handle on what you guys are
doing and, hopefully, you understand what we are up to in Canada.  I
think a follow-on conference is needed at some point but we should all
sit back and digest this one for a while.  Tom Keenan
=========================================================================
Date:         Mon, 24 Oct 88 19:10:23 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Pedro Sepulveda J." <PSEPULVE@USACHVM1>
Subject:      JV Virus...

    Hi Networkers...!

              We are  a group of  student of the  'Universidad de
    Santiago  de  Chile'  with   a  special  interest,  'Computer
    Viruses'.

              Our  investigations are  oriented on  the Jerusalem
    Virus (also  known as  the 'Hebrew University  Virus'), since
    that JV only has come at this moment. Due to circumstances of
    the educational  ambient, we  want to  protect our  works and
    resources.

              We are disassembling the greater part of the JV.

              If  you are  interested in  our work  and you  have
    information too, we would can to join efforts for to learn of
    the viruses  instead of to  be prejudiced  for its and  so to
    direct this knowledges for good road.

Pedro Sepulveda J.
Universidad de Santiago de Chile
=========================================================================
Date:         Mon, 24 Oct 88 14:51:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         ACS045@GMUVAX
Subject:      Conference

I myself found the size of the conference to actually be a boon more than
anything else...it was a lot easier to disseminate information across a
table than across the room, and I found it to be quite informative.
Thanks to Loren and all the others who helped make this possible
and I'd like to toss in a special thanx to the guys from Calgary and Cornell
who helped in carting me around this weekend----it was and is much appreciated.
Overall I'd say it was a successful and quite informative meeting.....
---------------
Steve Okay      [e-mail]/[e-mail]/CSR032 on The Source
                      "Ahhh...the keyboard...how quaint"
=========================================================================
Date:         Tue, 25 Oct 88 08:44:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Shawn V. Hernan" <VALENTIN@PITTVMS>
Subject:      RE: CMU and the virus

The virus that hit CMU was "nVIR", as named by interferon 3.1. It is apparantly
the same one that hit Pitt (which is about a block and a half away) two
weeks ago. Incidentally, here at Pitt we seemed to have eradicated the virus
very quickly. Thanks to everyone who gave suggestions on informing users about
it. They worked well, and we have seen no incidents of the virus since
early last week. I know because I take classes at CMU and Pitt. (Perhaps
I was the unknowing culprit!?!) Anyway, happy-virus hunting.


                                                Shawn Hernan
                                                University of Pittsburgh
=========================================================================
Date:         Tue, 25 Oct 88 13:17:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Shatner and Nimoy in '92! <PGOETZ@LOYVAX>
Subject:      Once more...

OK, I think I've posted this message a dozen times on different groups...

IF you have something to say, PLEASE specify what machine you are talking
about.

I'm specifically thinking of the many references we've had to anti-viral
programs (like FLUSHOT) and anti-viral libraries, which NEVER mention what
machine they run on.  Usually you can assume this means an IBM PC, since only
IBM users are arrogant enough to believe that no other machines exist. : )
=========================================================================
Date:         Mon, 24 Oct 88 11:31:41 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         SHERK@UMDD
Subject:      PC disk diagnostics- destructive?
In-Reply-To:  Message received on Fri, 21 Oct 88  13:02:30 EDT


>When I worked for a company which sold PC's we burned them in before
>delivery by stressing them as much as possible.  One of the things
>we did to test drives was to run the diagnostics continuously
>overnight.  It turned up some defective machines (which we returned)
>but I don't remember the ones we sent on to our customers coming
>back with problems in the drives at a higher rate than the machines
>I fixed which we had not burned in.

>Based on this I conclude that the PC diagnostic seek test is
>non-destructive (despite the noise).  If anyone has any actual
>experience to the contrary PLEASE post it.
You are right, it does no harm. In fact, with a little lubrication
it doesn't even make much noise.

Erik Sherk
Workstation Programer
University of Maryland
=========================================================================
Date:         Wed, 26 Oct 88 00:49:44 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Mark S. Zinzow" <MARKZ@UIUCVMD>
Subject:      UIUC Brain update



What has been done about our Brain virus infection:

1)  As previously noted the Brain virus was discovered here on Thursday
    October 20, 1988.  Since then, we have guestimated that the infection
    had spread for at least three weeks undetected.

2)  Information files and programs have been obtained from Lehigh, NBBS,
    Bitnic, and other sources.

3)  Files and programs distributed on campus via anonymous ftp
    from uxe.cso.uiuc.edu (128.174.5.54).

4)  Our samples of the Brain virus have been compared to the known
    original version to determine that we have a mutant which might be
    more dangerous than the original.  Ours has a different message at
    the beginning, so may behave differently than the known version.
    Once difference is the string "VIRUS_SHOE  RECORD   v9.0" shortly
    after the "Welcome to the Dungeon" message in the boot sector.

What remains to be done:

1)  A simple summary of all the useful anti-virus measures needs to be
    written and distributed to PC Users at large and all labs.
    (This should include information on other viruses and general
    protection measures.)

    This document will serve in the interim along with BRAIN.MCPART_T.

2)  Our samples of the Brain virus need to be analyzed and disassembled
    to see how it behaves relative to the original Brain.

3)  Some of the programs we have which check for and remove the brain
    virus need to be evaluated, and/or compiled, debugged, and
    distributed.  We should also check the software available on Simtel20,
    and Dave Chamber's BBS for his program V-finder.


Files Available on              Description                     Source
uxe in /micro/pc/virus
or pc/virus from anonymous ftp

VIRUS-L.FILELIST   List of files available from Lehigh U.  ListServ@LEHIIBM1
VIRUS-L.LOG88*     Logs of Bitnet virus discussion list    ListServ@LEHIIBM1
b88*         Excerpts from the above for quick reading   [e-mail]
BRAIN.MCPART_T     Good article on the first Brain virus   ListServ@BITNIC
debrain.exe        Program to check for and remove Brain   [e-mail]
virdoc2.txt        General virus documentation             Homebase BBS
review.pro         A review of protection software         VIRUS-L.LOG8806
README.virus       This file                            [e-mail]

Complete listing of the above directory at the time of this writing:

BRAIN.MCPART_T          VIRUS-L.LOG8808A        VIRUS.CERNY_J
CHECKMEM.C              VIRUS-L.LOG8808B        VIRUS.SHEEHA_M
CHKUP14.UUE             VIRUS-L.LOG8808C        b8804
NOBRAIN.C               VIRUS-L.LOG8808D        b8805
RISKS.LOG               VIRUS-L.LOG8808E        b8806
VIRUS-L.FILELIST        VIRUS-L.LOG8809A        b8807
VIRUS-L.LOG8806A        VIRUS-L.LOG8809B        book
VIRUS-L.LOG8806B        VIRUS-L.LOG8809C        debrain.exe
VIRUS-L.LOG8806C        VIRUS-L.LOG8809D        dir
VIRUS-L.LOG8807A        VIRUS-L.LOG8809E        readme.debrain
VIRUS-L.LOG8807B        VIRUS-L.LOG8810A        review.pro
VIRUS-L.LOG8807C        VIRUS-L.LOG8810B        virdoc2.txt
VIRUS-L.LOG8807D        VIRUS-L.LOG8810C
VIRUS-L.LOG8807E        VIRUS-L.LOG8810D

Files Available on              Description                     Source
uxe in /micro/pc/exec-pc/new
or pc/exec-pc/new
fsp_14.arc              Flushot Plus 1.4                Exec-PC BBS, Milw. WI
Many interesting files are here, but this the one of primary interest.
See the files xfer*.arc for complete descriptions of all Exec-PC files
through Oct. 17, 1988 including those kept here.
(note: Files from Exec-PC are put first in the new directory
       on uxe, then moved to exec-pc when the next batch is added.)

Files Available on              Description                     Source
uxe in /micro/pc/mac/virus
or pc/mac/virus
DUKVACC.TXT      Vaccine for "Dukakis" HyperCard virus  ListServ@SCFVM (NASA)
NVIRVACC.SITHQX  Vaccine for nVIR virus                 ListServ@SCFVM (NASA)

-------Electronic Mail----------------------------U.S. Mail--------------------
ARPA: [e-mail]         Mark S. Zinzow, Research Programmer
BITNET: [e-mail]         University of Illinois at Urbana-Champaign
CSNET: [e-mail]      Computing Services Office
 "Oh drat these computers, they are  150 Digital Computer Laboratory
   so naughty and complex I could    1304 West Springfield Ave.
  just pinch them!"  Marvin Martian  Urbana, IL 61801-2987
USENET/uucp: {ihnp4,convex,pur-ee,cmcl2,seismo}!uiucdcs!uiucuxc!uiucuxe!zinzow
(Phone: [phone]  Office: CSOB 110) ihnp4!pyrchi/         \markz%uiucvmd
=========================================================================
Date:         Wed, 26 Oct 88 09:11:52 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments:     Resent-From: RBCSCG05 <COSTERHD@SFAUSTIN>
From:         RBCSCG05 <COSTERHD@SFAUSTIN>


              Thought this should be forwarded here !!
                    RECEIVED  26 OCT 1988 @ 9:11


Chris Osterheld  <[e-mail]>


    Sent: 10/26/88 03:49  Rcvd: 10/26/88 03:49  Number: 4
      To: COSTERHD@SFAUSTIN                       From: MAC-USER
 Subject: !! VIRUS WARNING !!







Date:         Wed, 26 Oct 88 08:13:28 ECT
Reply-To:     EARN Macintosh Users List <MAC-USER@IRLEARN>
Sender:       EARN Macintosh Users List <MAC-USER@IRLEARN>
From:         Christian Falk 7-593891 <FALK@NORUNIT>
To:           Chris Osterheld <COSTERHD@SFAUSTIN>

Today, I received an upgrade disk from High Performance Systems INC, containing
STELLA 2.0 for Academe. Both STELLA and System files contained the
nVIR-resources.I have noticed the company.
Please forward this note !



=========================================================================
Date:         Wed, 26 Oct 88 10:11:25 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David M. Chess" <CHESS@YKTVMV>
Subject:      read-only, again

SSAT@PACEVM suggests that making command.com and the system files
read-only should be part of a virus-protection scheme.  While it
can't hurt (unless it leads to a false sense of security), and
it may prevent you from some accidents, it is trivial (a couple
dozen bytes of code) for a virus to alter a file despite the
fact that it is marked read-only.  All the viruses for PC-DOS
that I've seen in fact do this, and aren't even slowed down
by a read-only setting.

For that matter, except for the Lehigh COMMAND.COM virus, the
viruses that I've seen don't touch (or don't have to touch)
either COMMAND.COM or any of the system files.  The Jersulem
virus, for instance, spreads between normal (non-system) EXE and
COM files (I forget whether or not it will infect COMMAND.COM
given the chance; but it doesn't *have* to be able to).

So, as has been said here a couple of times before, read-only
is very very little help against viruses.

DC
=========================================================================
Date:         Wed, 26 Oct 88 13:00:00 PDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "JOHN D. WATKINS" <WATKINS@UCRVMS>
Subject:      hardware damage

  Hmm...the space shuttle uses magnetic core memory!  So where are the
temp sensors...

  Kevin
=========================================================================
Date:         Wed, 26 Oct 88 19:36:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Paul Coen <PCOEN@DRUNIVAC>
Subject:      LISTSERV@RPICICGE


Quite a few people have been referring to the LISTSERVer at RPICICGE as a
source for files (SIMTEL20 redistribution).  I thought I'd post this message
John Fisher sent out on PCSERV-L some time ago.

>From:  BITNET%"FISHER@RPICICGE"      "John S. Fisher" 22-SEP-1988 10:25:45.04
>To:    Paul Coen <PCOEN@DRUNIVAC>
>CC:
>Subj:  Unhappy state of affairs
>
>Received: From BITNIC(MAILER) by DRUNIVAC with Jnet id 4235
>          for PCOEN@DRUNIVAC; Thu, 22 Sep 88 10:25 EDT
>Received: by BITNIC (Mailer X1.25) id 4233; Thu, 22 Sep 88 10:29:35 EDT
>Date:         Thu, 22 Sep 88 09:45:24 EDT
>Reply-To:     Public domain software servers <PCSERV-L@RPICICGE>
>Sender:       Public domain software servers <PCSERV-L@RPICICGE>
>From:         "John S. Fisher" <FISHER@RPICICGE>
>Subject:      Unhappy state of affairs
>To:           Paul Coen <PCOEN@DRUNIVAC>
>
>The PC software server available through LISTSERV@RPICICGE (and shadowed by a
>few TRICKLE servers) has not been doing very well lately.  Well, that is being
>polite.  This has been one rotten summer for the server.  The cheap excuse of
>Simtel20 being down for a major part of August is just that, cheap.  Had it
>been up the whole time, the server here would probably not have noticed.
>
>The server gets its files via FTP over the internet direct from Simtel20.  At
>least that is what it tries to do.  My system is connected to one of the NSF
>regional networks (NYSERNET in this case).  That in turn is connected via
>gateways to the various other networks that make up the internet.  The path
>from NYSERNET to MILNET (where Simtel20.ARMY.MIL is to be found) has been
>extremely unreliable for quite some time.  In the spring of this year the
>server was able to move 100-200 files per day in response to requests (with
>the balance of requests being satisified from a local cache of popular files).
>
>For most of the summer the transfer rate has never exceeded 20.  For one solid
>week now the total number of files transfered is exactly zero.
>
>The server is providing no service at all.
>
>Actually, it is providing a disservice by giving the impression it will
>really do something.  Enough.  If by Monday of next week (26 October 88) there
>is no ray of hope for improved connectivity between here and Simtel20, service
>will be discontinued.  There is not necessarily any group of individuals or
>network equipment at fault, either; the situation simply is what it is.  So, I
>should face reality and stop pretending to be able to do something that I can
>not.
>
>Be that as it may, there are many of you out there on Bitnet, running some
>flavor of VM, connected to the internet by either FAL or WiscNet, who
>actually can get to Simtel20 reliably.  I'm looking for volunteers, people
>willing and able to provide access to all or some (one even) of the many
>archives available at Simtel20.  If you have the system, I have the software.
>
>
>Regards,
>JSFisher

I have not heard any updates on the situation, so I assume little has changed.
Has anyone heard differently?

+----------------------------------------------------------------------------+\
| Paul R. Coen                                                               | |
|   Bitnet: PCOEN@DRUNIVAC       U.S. Snail:  Drew University CM Box 392,    | |
|           PCOEN@DREW                        Madison, NJ 07940              | |
|   Disclaimer:  I represent my own reality.                                 | |
+----------------------------------------------------------------------------+ |
\                                                                             \|
 \_____________________________________________________________________________\

=========================================================================
Date:         Thu, 27 Oct 88 00:17:21 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         GX6692@SIUCVMB
Subject:      HELP!

   I was sent to this list by some people from another list (GAMES-L)since
I mentioned a virus on that list etc...
   It seems that our school has just been hit with what has become commonly
known as the Pakistan virus. I personally have lost MANY hours of work
to this bug. If ANYONE can help me (so that I may help others) on how
to deal with this PLEASE let me know ASAP.  The virus hit here so bad that
we made the St. Louis Post Dispatch (newspaper), Tribune (Chicago newspaper),
and a few other lesser newspapers etc...
   I work at one of the Computer Labs here at school. My job is mostly to
help people and distribute software. The problem is that our school software

has also been VERY much affected. So you can see that we are up a certain
creek without a mode of propulsion.
   Thanks for all your help in advance...

                             vince laurent
                             GX6692@SIUCVMB
=========================================================================
Date:         Thu, 27 Oct 88 11:21:00 LCL
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "H.Ludwig Hausen [phone]" <HAUSEN@DBNGMD21>
Subject:      Re: Dissertation Copy?

Hello, I would like to know this source also. So , please e-mail
the address if you get one. Thanks. HL. Hausen
o----------------------------------------------------------------------o
| GMD Schloss Birlinghoven       Telefax   [phone]            |
| D-5205 Sankt Augustin 1        Teletex   2627-224135=GMD VV          |
|        West  GERMANY           Telex     8 89 469 gmd d              |
|                                E-mail    [e-mail]      |
|                                Telephone [phone] or 2426    |
o----------------------------------------------------------------------o
|    GMD (Gesellschaft fuer Mathematik und Datenverarbeitung)          |
|    German National Research Institute of Computer Science            |
|    German Federal Ministry of Research and Technology (BMFT)         |
o----------------------------------------------------------------------o
=========================================================================
Date:         Thu, 27 Oct 88 11:12:18 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David M. Chess" <CHESS@YKTVMV>
Subject:      UIUC Brain update

>                                ...  Ours has a different message at
>  the beginning, so may behave differently than the known version.
>  Once difference is the string "VIRUS_SHOE  RECORD   v9.0" shortly
>  after the "Welcome to the Dungeon" message in the boot sector.

Although I can't of course know that it's the same thing that you
have, it may be somewhat comforting to know that I've seen a virus
with the "VIRUS_SHOE" wording in it, and that it proved to be exactly
identical to the standard "Brain" virus, except for the unused
text areas.  The readable parts of the boot record in the variant
that I've seen included:

     Welcome to the Dungeon  (c) 1986 Brain & Amjads (pvt) Ltd
     VIRUS_SHOE RECORD v9.0   Dedicated to the dynamic memories
     of millions of virus who are no longer with us today -
     Thanks GOODNESS !!   BEWARE OF THE er VIRUS  :  this
     program is catching    program follows after these messeges

"Thanks GOODNESS" and "messeges" are the originator's typos, not
mine!   The string "(c) Brain" had also been replaced with the
string "(c) ashar" in one place.   But all the code was identical.
I first encountered this variant in Paris, and have since seen it
in a university in Texas.

Don't be too comforted by this, of course!  It may well be that
someone has taken the original variant and added nasty things to
it.   So be very careful, and do have your technical-types dig
into it.

Dave Chess
Watson Research
=========================================================================
Date:         Thu, 27 Oct 88 18:24:08 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Chip McGuill <PINKY@TAMCBA>
Subject:      Detection

I need some detailed information on detection and the prevention of
viruses on MSDOS computers.
Please post to me directly.
Thanks.


/^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^!^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\
:  Chip McGuill                   !                                  :
:  Academic Computer Center       !  <PINKY@TAMCBA>                  :
:  Texas A & M University         !  <N166AY@TAMVM1>                 :
:  129 Blocker                    !__________________________________:
:  College Station, TX  77840     !  Disclaimer:  Everything I say   :
:                                 !  has nothing to do with whom I   :
:  [phone]                 !  work for.                       :
\_________________________________!__________________________________/
=========================================================================
Date:         Thu, 27 Oct 88 16:08:19 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         me! Jefferson Ogata <OGATA@UMDD>
Subject:      LaserWriters and memory

I am forwarding this message about LaserWriters to the list at the
author's request.

  Subject: LaserWriter hacking

  Some of the LaserWriter's memory is not erased at power-down - I don't
  know the exact technology used, some sort of EPROM, I suppose.  But the
  password is stored in it.  It is possible to change the password (null
  in most networks) over the AppleTalk so that only you can use the
  printer.  The only fix is to send the machine back for a new, blank,
  EPROM, since the password protects the printer against future attempts
  at password modification.

  I haven't done this; I know about it from someone who worked out how to
  do it but refrained from trying the experiment.

  best wishes - jack

  Jack Campin,  Computing Science Department,
  Glasgow University, 17 Lilybank Gardens, Glasgow G12 8QQ, SCOTLAND.
  041 339 8855 x6045 wk 041 556 1878 ho
  ARPA: [e-mail]  USENET: [e-mail]
  JANET: [e-mail]
  PLINGnet: ...mcvax!ukc!cs.glasgow.ac.uk!jack
[end of forwarded message]

A little info about memory: most computer memory these days is comple-
mentary metal-oxide semiconductor (CMOS) technology.  Because of power
and price, dynamic memory is used for storage.  Dynamic memory must be
periodically refreshed, or it forgets things.  Since this refreshing
process requires external logic or an active processor, static memory is
used for non-volatile applications.  Static memory does not need to be
refreshed, but tends to use more power.  So CMOS low-power (LP) static
memory is used; these devices have an inactive low-power mode that can be
maintained for a long time with an onboard battery power supply.

EPROMs cannot be re-written after having been programmed, unless they are
erased with ultraviolet light.  Many distribution EPROMs these days can
never be erased, since they are encased in solid epoxy carriers.  These
devices are technically PROMs, however, they are the same devices as the
EPROMs, in cheaper packaging.  Eraseable EPROMs come in ceramic carriers
with a quartz window on top.

EEPROMs can be electrically erased, so they may be used on a board as
non-volatile memory, but the support circuitry required to erase them and
reprogram them makes such applications impractical.  In fact, EEPROMs
themselves are pretty impractical, and not widely used.  The support
circuitry required to program a simple EPROM is impractical as well.
Programming any kind of EPROM typically requires a 21V or 25V power
supply, and most computers don't need such voltages for any other pur-
pose.  So onboard EPROM programmers are also quite rare.

Here are a few acronyms:
CMOS:    complementary metal-oxide semiconductor
CMOS-LP: complementary metal-oxide semiconductor - low power
PROM:    programmable read-only memory
EPROM:   eraseable programmable read-only memory
EEPROM:  electrically eraseable programmable read-only memory

- Jeff Ogata

Gee...maybe I should move this over to MEMORY-L... :-)
=========================================================================
Date:         Thu, 27 Oct 88 18:55:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Dimitri Vulis <DLV@CUNYVMS1>
Subject:      Hardware damage

A virus does not actually have to _damage_ the hardware; it may achieve
the same results by programming it to operate it in such a manner that
it appears damaged. For example, suppose a PostScript trojan causes
black and white streaks to appear at random on printed pages; you're
going to have your printer serviced, and it'll cost you the same (in
terms of time and money) as if it were broken. Or, a virus might
create bad sectors on a hard disk, causing you to replace the disk. The
possibilities are endless, and it's much easier to do (and hence more
dangerous) than outright hardware damage.
-Dimitri Vulis
-Math Dept, CUNY Graduate Center
=========================================================================
Date:         Fri, 28 Oct 88 10:42:49 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Re: HELP!
In-Reply-To:  Message from "[e-mail]" of Oct 27,
              88 at 12:17 (midnight)

>
>   I was sent to this list by some people from another list (GAMES-L)since
>I mentioned a virus on that list etc...
>   It seems that our school has just been hit with what has become commonly
>known as the Pakistan virus. I personally have lost MANY hours of work
>to this bug. If ANYONE can help me (so that I may help others) on how
>to deal with this PLEASE let me know ASAP.  The virus hit here so bad that
>we made the St. Louis Post Dispatch (newspaper), Tribune (Chicago newspaper),
>and a few other lesser newspapers etc...
>   I work at one of the Computer Labs here at school. My job is mostly to
>help people and distribute software. The problem is that our school software
>
>has also been VERY much affected. So you can see that we are up a certain
>creek without a mode of propulsion.
>   Thanks for all your help in advance...
>
>                             vince laurent
>                             GX6692@SIUCVMB
>

Not to be unhelpful, but where is this from?

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
=========================================================================
Date:         Fri, 28 Oct 88 16:42:19 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Dorothy White <DWHITE@UMAB>
Subject:      Re: Dissertation Copy?
In-Reply-To:  note of Thu,
              27 Oct 88 11:21:00 LCL from "H.Ludwig Hausen +49-2241
              <HAUSEN@DBNGMD21>

From: DWHITE AT UMAB

I RECEIVED IT=========================================================================
Date:         Sat, 29 Oct 88 14:13:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         TFD@CUNYVMS1
Subject:      UUDECODE.PAS

Can anyone tell me what version of PASCAL the above program is in??
I requested it from LISTSERV@LEHIIBM1, and now I can't budge it. My
diagnostics give me tons of error messages. Perhaps it's just not the
same version as I'm using(?)
=========================================================================
Date:         Sun, 30 Oct 88 11:00:39 PLT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Wim Bonner <27313853@WSUVM1>
Subject:      Re: UUDECODE.PAS
In-Reply-To:  Message of Sat, 29 Oct 88 14:13:00 EST from <TFD@CUNYVMS1>

That version of UUDECODE is for turbo pascal 3.0.  As turbo 5.0 just
arrived at my door yesterday, I may undertake re-coding it so that it
will run under the newest version, but as I am a student, and not
currently taking Pascal, but am taking C Courses, I may just play around
with the new C stuff.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=- 10,000 Lemmings can't be wrong! -=-=-=-=-=-=-=-=-
=-=-=-=-=-=-=-= Lemmings never grow old, they just die. =-=-=-=-=-=-=
Wim Bonner  Bitnet:27313853@WSUVM1  Compuserve:72561,3135  (King-Rat)
The Loft - [phone] - 300/1200/2400 - 24hrs/day - PCboard 12.1/d
=========================================================================
Date:         Sun, 30 Oct 88 18:57:16 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         SSAT@PACEVM

does anyone know where i can get debrain.exe or for that matter any and
all types of anti-viral software for the ibm pc family?
=========================================================================
Date:         Mon, 31 Oct 88 00:03:00 CST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         TP19000 <TP19000@SDSUMUS>

In-Reply-To: In reply to your message of SUN 30 OCT 1988 16:57:16 EDT

Hello my name is Matt Johnson.

I am also interested in recieving anti-viral software.
If you find out anything I would aprecate it if you would drop
me a line. I'm at the SDSUMUS node and my ID number is TP19000.
Thank You.
=========================================================================
Date:         Mon, 31 Oct 88 00:23:41 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David A. Bader" <DAB3@LEHIGH>
Subject:      Anti-Viral Software

I think that we all are interested in Anti-Viral software.  Instead of
having everyone post a memo here requesting such, how about having it
in UUENCODED format on the ListServ? (Any ideas, Ken?)
       -David Bader
        DAB3@LEHIGH
=========================================================================
Date:         Mon, 31 Oct 88 08:02:23 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ken van Wyk <[e-mail]>
Subject:      Re: UUDECODE.PAS
In-Reply-To:  Your message of Sat, 29 Oct 88 14:13:00 EST

> Can anyone tell me what version of PASCAL the above program is in??

The uudecode.pas program on the LISTSERV at LEHIIBM1 is written for
Turbo Pascal v 3.0 on a DOS-based PC.

Ken

=========================================================================
Date:         Mon, 31 Oct 88 10:23:02 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         SHERK@UMDD
Subject:      Debrain.exe
In-Reply-To:  Message received on Sun, 30 Oct 88  18:11:01 EST

Debrain.exe is available through anonymous ftp @ umd5.umd.edu
Cd into the /pub directory. There is a readme file, a Turbo C source file,
and an executable version.

Erik Sherk
Workstation Programmer
Computer Science Center
University of Maryland
[e-mail]
=========================================================================
Date:         Mon, 31 Oct 88 08:55:00 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David D. Grisham" <DAVE@UNMB>
Subject:      A new one on me.


Hi group,
One of our student consultants mailed this to me.  Note:  This happened
in a Mac Lab, with 512s and SEs.  I don't have a copy of this yet.
HAS ANYONE HEARD OF THIS TROJAN OR VIRUS?
---
         This afternoon, I found that we have what I think is some form
of mutated virus.  IT CHANGED MY VIRUS RX PROGRAM TO A GENERIC DOCUMENT
ENTITLED "PLEASE THROW ME IN THE TRASH".  This is no joke.  It did it right
in front of my eyes.
I got a message box, which stated "There is a penetration attempt
on VirusRx, if the disc is unlocked, it will be changed
to "Please throw me in the trash"".
        This sounded like so much BS to me, but when I looked, IT WAS
NO JOKE!  I don't have any time to devote to isolation because of comps
this Wed.  Joseph has the altered VirusRx (now a 44k generic document).
Let me know your thoughts on this subject.
----

******************************************************************************
*                                                                            *
*   Dave  Grisham                                                            *
*   Senior Staff Consultant/Virus Security          Phone [phone]     *
*   Information Resource Center                                              *
*   Computer & Information Resources & Technology                            *
*   University of New Mexico                        USENET [e-mail] *
*   Albuquerque, New Mexico  87131                  BITNET DAVE@UNMB         *
*                                                                            *
******************************************************************************
=========================================================================
Date:         Mon, 31 Oct 88 10:38:40 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      FEV and EEV, long memo


Let me suggest a couple of definitions.  We have two sorts of ways
virii carry on their work, either by using a known and expected system
feature, or by using a systemic bug or error.  In either case, the
virus infects files, but the problem, understanding and solution to
the two cases is different.

In one case a system feature, the ability to set the date in the MSDOS
world at the user level, allows a virus to infect a file (which
normally would cause the file to have the date of last writing set to
the present date and time) and then reset the file's date to what it
was before infection.  We know this, we are aware that in MSDOS there
is no way to prevent it, and our problems and solutions work in such a
way that the date on a file must mean little or nothing.

In another case, in a VMS system, where a file's last write date is
system enforced, a user can depend on a file having its date changed
if it is written to by a virus.  Of course, if a bug in VMS were to
permit a user to change the date on a file (not normally allowed to an
ordinary user by VMS) that error would permit a virus to do the same
as above.

Our method of attack in the second case would be to fix the error.

Our method of attack in the first case would have to be some other
approach.

The point of this lengthening memo is to stress the difference between
the two kinds of virii, those that exploit errors (Error Exploiting
Virii or EEV) and those that expoloit system features (Feature
Exploiting Virii or FEV).  In the case of the FEV when we see such a
virus, we generally nod sagely and say "that is caused by the ___
feature of the system and such a feature must be avoided".  In the
case of the EEV we first state with alarm "That cannot be done!".
Then we examine the detail of the (fill in the blank here) program,
note that it has a defect and only then say "The program ___ has a
defect. Let us fix it and then never again will the system be unsafe."

Some nice examples:  I recently heard about a virus that infects the
hard disk and survives a reformatting of the hard disk, but not a low
level reformatting.  Might this virus do a low level format of track 0
of the hard disk and create 18 rather than 17 blocks on that disk?
(We know that a low level reformat of a hard disk can be done without
loss of data, spinrite does it.)  If there were two blocks named 0,
then when Format was executed, only the first block 0 found would be
reformatted, the other would go unnoticed.  Later, when the system was
rebooted, the chance of getting the second block 0 rather than the
first, would depend on the relative distance between them on the disk.
In the worst case it would be 1/18, in the best case 1/2.  An error in
the way format finds blocks to reformat on a hard disk will support
this EEV virus in its method of hiding.

A second example:  A recent NET letter discusses a potential virus
that might work in the UNIX environment by creating a second copy of a
program used in normal file allocation routines.  This ghost copy is
written at the source level by a program that would come hidden with some
trojan horse package.  Once installed, the virus would install its own
version of the allocation code which does whatever it does.  No system
error is needed for this FEV virus, only an careless UNIX root owner
who installs code that works without very careful examination of the
sources.

Sorry about the length of this, but this point about FEV and EEV seems
worth discussing.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
=========================================================================
Date:         Mon, 31 Oct 88 13:26:42 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David M. Chess" <CHESS@YKTVMV>
Subject:      FEV and EEV

I think that's a worthwhile distinction (although there could be
viruses that are halfway between; that would spread in a correct
system, but spread even better in one with a certain error).

A couple of small points:

> Then we examine the detail of the (fill in the blank here) program,
> note that it has a defect and only then say "The program ___ has a
> defect. Let us fix it and then never again will the system be unsafe."

Not "never again", surely!   Even in the example you cite, once you've
fixed ___ so that the virus can no longer meddle with dates, it can
still spread, and only if users bother to check the dates on the
executables to which they have write access will the virus be in
trouble.   It will not spread as well as it used to, but it may
still spread.   Even if the error-virus relationship was such
that the virus depended on the error for its very life, all you
could say after fixing the error was "never again will the system
be in danger from this exact virus".   I know that's what you meant...

>          ...         I recently heard about a virus that infects the
> hard disk and survives a reformatting of the hard disk, but not a low
> level reformatting.  Might this virus do a low level format of track 0
> of the hard disk and create 18 rather than 17 blocks on that disk?

Well, possibly. But more likely (if this was a PC-DOS virus) it's
just that the thing alters the hard disk boot record.  A normal
DOS FORMAT will not (as I understand it) rewrite a hard disk's
boot record if there's already one in place.  Only a "low level"
format does that.  (Both kinds of formats apparently write a new
boot record on floppy disks.)

DC
=========================================================================
Date:         Mon, 31 Oct 88 15:58:49 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Re: FEV and EEV
In-Reply-To:  Message from "David M. Chess" of Oct 31, 88 at 1:26 pm

>> Then we examine the detail of the (fill in the blank here) program,
>> note that it has a defect and only then say "The program ___ has a
>> defect. Let us fix it and then never again will the system be unsafe."
>
>Not "never again", surely!   Even in the example you cite, once you've

I knew that.  Just a bit of humor.

>Well, possibly. But more likely (if this was a PC-DOS virus) it's
>just that the thing alters the hard disk boot record.  A normal
>DOS FORMAT will not (as I understand it) rewrite a hard disk's
>boot record if there's already one in place.  Only a "low level"
>format does that.  (Both kinds of formats apparently write a new
>boot record on floppy disks.)
>

In any event, the error would be marked as a FEV or EEV and would be
dealt with accordingly.


+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
=========================================================================
Date:         Mon, 31 Oct 88 18:20:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         TFD@CUNYVMS1
Subject:      thanks

I hope nobody thinks I'm hogging the net because I'm writing to thank
lotsa people for replying to my problem with such alacrity, over the list, and
directly to me!
Anyway, a real smart guy (and a sharp dresser) here at CUNY is going to help me
out, and if that doesn't work out, I'll take one of you up on your generous
offers . . .
Thanks again,
Theresa Muir
=========================================================================
Date:         Mon, 31 Oct 88 15:25:51 PLT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Wim Bonner <27313853@WSUVM1>
Subject:      Re: Debrain.exe
In-Reply-To:  Message of Mon, 31 Oct 88 10:23:02 EST from <SHERK@UMDD>

If possible, when people post where code is available via FTP, could
you also list the network numbers?  I am interested in getting the Dbrain
code, but Our machine which can do FTP does not have a full listing of
hosts.  I can call out if I know the number though.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=- 10,000 Lemmings can't be wrong! -=-=-=-=-=-=-=-=-
=-=-=-=-=-=-=-= Lemmings never grow old, they just die. =-=-=-=-=-=-=
Wim Bonner  Bitnet:27313853@WSUVM1  Compuserve:72561,3135  (King-Rat)
The Loft - [phone] - 300/1200/2400 - 24hrs/day - PCboard 12.1/d